Method and Apparatus for Performing Network Based Service Access Control for Femtocells

ABSTRACT

Some embodiments are implemented in a communication system that includes a first wireless communication system and a second wireless communication system that includes a Femtocell access point (FAP) and a network controller that can communicatively couple the FAP to the first wireless communication system. In some embodiments, the network controller can communicatively couple to the first wireless communication system through a UTRAN Iu interface. Some embodiments provide a resource management method that determines that a user equipment (UE) has roved in a region serviced by the FAP. The FAP includes a generic access resource control (GA-RC) protocol sub-layer. The method creates a separate GA-RC state dedicated to the UE in the GA-RC protocol sub-layer. The method also sets the GA-RC state dedicated to the UE to a deregistered state to indicate that the UE is not registered to use the services of the second wireless communication system.

CLAIM OF BENEFIT TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application60/826,700, entitled “Radio Access Network—Generic Access to the IuInterface for Femtocells”, filed Sep. 22, 2006; U.S. ProvisionalApplication 60/869,900, entitled “Generic Access to the Iu Interface forFemtocells”, filed Dec. 13, 2006; U.S. Provisional Application60/911,862, entitled “Generic Access to the Iu Interface forFemtocells”, filed Apr. 13, 2007; U.S. Provisional Application60/949,826, entitled “Generic Access to the Iu Interface”, filed Jul.13, 2007; U.S. Provisional Application 60/884,889, entitled “Methods toProvide Protection against service Theft for Femtocells”, filed Jan. 14,2007; U.S. Provisional Application 60/893,361, entitled “Methods toPrevent Theft of Service for Femtocells Operating in Open Access Mode”,filed Mar. 6, 2007; U.S. Provisional Application 60/884,017, entitled“Generic Access to the Iu Interface for Femtocell—Stage 3”, filed Jan.8, 2007; U.S. Provisional Application 60/911,864, entitled “GenericAccess to the Iu Interface for Femtocell—Stage 3”, filed Apr. 13, 2007;U.S. Provisional Application 60/862,564, entitled “E-UMA—Generic Accessto the Iu Interface”, filed Oct. 23, 2006; U.S. Provisional Application60/949,853, entitled “Generic Access to the Iu Interface”, filed Jul.14, 2007; and U.S. Provisional Application 60/954,549, entitled “GenericAccess to the Iu Interfaces—Stage 2 Specification”, filed Aug. 7, 2007.The contents of each of the above mentioned provisional applications arehereby incorporated by reference.

FIELD OF THE INVENTION

The invention relates to telecommunication. More particularly, thisinvention relates to a technique for seamlessly integrating voice anddata telecommunication services across a licensed wireless system and ashort-ranged licensed wireless system.

BACKGROUND OF THE INVENTION

Licensed wireless systems provide mobile wireless communications toindividuals using wireless transceivers. Licensed wireless systems referto public cellular telephone systems and/or Personal CommunicationServices (PCS) telephone systems. Wireless transceivers include cellulartelephones, PCS telephones, wireless-enabled personal digitalassistants, wireless modems, and the like.

Licensed wireless systems utilize wireless signal frequencies that arelicensed from governments. Large fees are paid for access to thesefrequencies. Expensive base station (BS) equipment is used to supportcommunications on licensed frequencies. Base stations are typicallyinstalled approximately a mile apart from one another (e.g., cellulartowers in a cellular network). The wireless transport mechanisms andfrequencies employed by typical licensed wireless systems limit bothdata transfer rates and range. As a result, the quality of service(voice quality and speed of data transfer) in licensed wireless systemsis considerably inferior to the quality of service afforded by landline(wired) connections. Thus, the user of a licensed wireless system paysrelatively high fees for relatively low quality service.

Landline (wired) connections are extensively deployed and generallyperform at a lower cost with higher quality voice and higher speed dataservices. The problem with landline connections is that they constrainthe mobility of a user. Traditionally, a physical connection to thelandline was required.

In the past few years, the use of unlicensed wireless communicationsystems to facilitate mobile access to landline-based networks has seenrapid growth. For example, such unlicensed wireless systems may supportwireless communication based on the IEEE 802.11a, b or g standards(WiFi), or the Bluetooth® standard. The mobility range associated withsuch systems is typically on the order of 100 meters or less. A typicalunlicensed wireless communication system includes a base stationcomprising a wireless access point (AP) with a physical connection(e.g., coaxial, twisted pair, or optical cable) to a landline-basednetwork. The AP has a RF transceiver to facilitate communication with awireless handset that is operative within a modest distance of the AP,wherein the data transport rates supported by the WiFi and Bluetooth®standards are much higher than those supported by the aforementionedlicensed wireless systems. Thus, this option provides higher qualityservices at a lower cost, but the services only extend a modest distancefrom the base station.

Currently, technology is being developed to integrate the use oflicensed and unlicensed wireless systems in a seamless fashion, thusenabling a user to access, via a single handset, an unlicensed wirelesssystem when within the range of such a system, while accessing alicensed wireless system when out of range of the unlicensed wirelesssystem. The unlicensed wireless communication systems, however, requirethe use of dual-mode wireless transceivers to communicate with thelicensed system over the licensed wireless frequencies and with theunlicensed system over the unlicensed wireless frequencies. The use ofsuch dual-mode transceivers requires the service providers to upgradethe existing subscribers' transceivers which operate only on licensedwireless frequencies to dual-mode transceivers. Therefore, there is aneed in the art to develop a system that provides the benefits of thesystems described above, without the need for dual-mode transceivers.

SUMMARY OF THE INVENTION

Some embodiments are implemented in a communication system that includesa first wireless communication system and a second wirelesscommunication system that includes a Femtocell access point (FAP) and anetwork controller that can communicatively couple the FAP to the firstwireless communication system.

In some embodiments, the network controller can communicatively coupleto the first wireless communication system through a UTRAN Iu interface.In some embodiments, the FAP can communicatively couple to a userequipment using a short-range licensed wireless frequency.

Some embodiments provide a resource management method that determinesthat a user equipment (UE) has roved in a region serviced by the FAP.The FAP includes a generic access resource control (GA-RC) protocolsub-layer. The method creates a separate GA-RC state dedicated to the UEin the GA-RC protocol sub-layer. The method also sets the GA-RC statededicated to the UE to a deregistered state to indicate that the UE isnot registered to use the services of the second wireless communicationsystem.

Some embodiments provide method that determines whether a UE hasroved-out of the second communication system. The method receives aperiodic message at the FAP from the UE. When the FAP fails to receive apre-determined number of the periodic messages, the method sends aderegister message to the network controller over a unique connectionbetween the FAP and the network controller which is dedicated to the UEand also releases the dedicated connection.

Some embodiments provide a method of that releases resources after theloss of connectivity. The method sends a periodic message from the FAPto the network controller over a connection between the FAP and thenetwork controller to determine whether the connection is lost. When theFAP determines that the connection is lost, the FAP deregisters a userequipment (UE) that is communicatively coupled with the FAP and forcesthe UE to perform a cell reselection.

Some embodiments provide a method that registers a Femtocell accesspoint (FAP). The method sends a register request message that includes aregistration type from the FAP to the network controller. Theregistration type identifies the FAP as a device to be registered withthe network controller. When the register request message is acceptableby the network controller, the FAP receives a register accept message.

Some embodiments provide a method for performing discovery. The methodsends a discovery request message that includes a licensed wireless cellinformation to a provisioning network controller. The method receives adiscovery accept message at the FAP. The discovery accept messageincludes identification of a default network controller determined basedon the cell information. The discovery accept message is sent by theprovisioning network controller when the provisioning network controllerdetermines that the provisioning network controller can accept thediscovery request message.

Some embodiments provide a method of performing a user equipment (UE)registration. The method establishes a unique connection dedicated tothe UE between the FAP and the network controller. The method receives aregister request message at the network controller from the FAP throughthe dedicated connection.

Some embodiments provide a security control method. The method receivesa security mode command that includes a set of security keys and a setof security algorithms at the FAP from the network controller, the setof security keys and the set of security algorithms are received at thenetwork controller from the first wireless communication system. Themethod determines the integrity of a set of messages that are exchangedbetween the FAP and a user equipment (UE) that is communicativelycoupled to the FAP through an air interface by using the set of securitykeys and the set of security algorithms.

Some embodiments provide method of providing security. The methodestablishes a secure tunnel between the FAP and the network controller.The method communicatively couples the FAP and several user equipments(UEs) to the network controller by using the secure tunnel. The UEs arecommunicatively coupled to the FAP through an air interface.

Some embodiments provide a method of preventing theft of service. Themethod creates an authorized session that includes a session identityfor a first user equipment (UE). The session is for communicativelycoupling the first UE with the first wireless communication systemthrough the FAP. The first UE is recognized by the first wirelesscommunication system as an authorized UE to use the FAP. The methodrejects a request by the FAP to register a second UE when the identityof the second UE does not match any identity in the set of first UEidentities. The rejected request includes the session identity of theauthorized session and the identity of the second UE. The second UE isnot recognized by the first wireless communication system as anauthorized UE to use the FAP.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth in the appendedclaims. However, for purpose of explanation, several embodiments of theinvention are set forth in the following figures.

FIG. 1 illustrates an integrated communication system (ICS) of someembodiments.

FIG. 2 illustrates several applications of an ICS in some embodiments.

FIG. 3 illustrates the overall A/Gb-mode GAN functional architecture ofsome embodiments.

FIG. 4 illustrates the overall Iu-mode GAN functional architecture ofsome embodiments.

FIG. 5 illustrates the Femtocell functional architecture of someembodiments.

FIG. 6 illustrates Femtocell network architecture of some embodimentswith an asynchronous transfer mode (ATM) interface towards the corenetwork.

FIG. 7 illustrates Femtocell network architecture of some embodimentswith IP interface towards the core network.

FIG. 8 illustrates CS Domain Control Plane Architecture of someembodiments.

FIG. 9 illustrates CS Domain User Plane Protocol Architecture of someembodiments.

FIG. 10 illustrates PS Domain Control Plane Architecture of someembodiments.

FIG. 11 illustrates PS Domain User Plane Protocol Architecture of someembodiments.

FIG. 12 illustrates the state diagram for Generic Access in the FAP ofsome embodiments.

FIG. 13 illustrates the state diagram in some embodiments for GA-CSR inthe FAP for each UE.

FIG. 14 illustrates the state diagram in some embodiments for GA-PSR inthe FAP for each UE.

FIG. 15 illustrates FAP initiated GA-CSR connection establishment insome embodiments.

FIG. 16 illustrates GA-CSR connection release of some embodiments.

FIG. 17 illustrates FAP initiated GA-PSR connection establishment ofsome embodiments.

FIG. 18 illustrates GA-PSR connection release in some embodiments.

FIG. 19 illustrates FAP power on discovery procedure of someembodiments.

FIG. 20 illustrates FAP power on registration procedure in someembodiments.

FIG. 21 illustrates the messages associated with the FAP initiatedsynchronization procedure in some embodiments.

FIG. 22 illustrates UE registration in some embodiments.

FIG. 23 illustrates UE Rove out in some embodiments.

FIG. 24 illustrates a scenario where the UE powers down and performs anIMSI detach in some embodiments.

FIG. 25 illustrates a scenario for loss of Up interface connectivity insome embodiments.

FIG. 26 illustrates FAP-initiated register update scenario of someembodiments.

FIG. 27 illustrates INC-initiated register update scenario in someembodiments.

FIG. 28 illustrates the FAP initiated synchronization procedure in someembodiments.

FIG. 29 illustrates voice bearer establishment procedures (for MO/MTcalls, using Iu-UP over AAL2) in some embodiments.

FIG. 30 illustrates the mobile originated mobile-to-PSTN call in someembodiments.

FIG. 31 illustrates a mobile terminated PSTN-to-mobile call in someembodiments.

FIG. 32 illustrates call release by Femtocell subscriber in someembodiments.

FIG. 33 illustrates an example of relay of DTAP supplementary servicemessages in some embodiments.

FIG. 34 illustrates FAP initiated GA-PSR Transport Channel activation insome embodiments.

FIG. 35 illustrates FAP initiated Transport Channel deactivation in someembodiments.

FIG. 36 illustrates network initiated Transport Channel Activation foruser data service in some embodiments.

FIG. 37 illustrates network initiated Transport Channel deactivation insome embodiments.

FIG. 38 illustrates Femtocell User Plane Data Transport procedures insome embodiments.

FIG. 39 illustrates Uplink Control Plane Data Transport of someembodiments.

FIG. 40 illustrates Downlink Control Plane Data Transport of someembodiments.

FIG. 41 illustrates the protocol architecture for CS mode SMS in someembodiments.

FIG. 42 illustrates the GAN protocol architecture for packet mode SMS insome embodiments.

FIG. 43 illustrates a mobile originated SMS transfer via GAN circuitmode in some embodiments.

FIG. 44 illustrates a CS mode mobile terminated SMS transfer viaFemtocell in some embodiments.

FIG. 45 illustrates a service area based routing scenario of someembodiments.

FIG. 46 illustrates GAN Femtocell security mechanisms in someembodiments.

FIG. 47 illustrates EAP-SIM authentication procedure in someembodiments.

FIG. 48 illustrates EAP-AKA authentication procedure of someembodiments.

FIG. 49 illustrates the message flow for security mode control in someembodiments.

FIG. 50 illustrates the AKA procedure used for mutual authentication insome embodiments.

FIG. 51 illustrates the high level procedure which can result in theftof service by a rogue FAP.

FIG. 52 illustrates the Femtocell service theft prevention approach ofsome embodiments.

FIG. 53 illustrates the Femtocell service theft prevention in someembodiments.

FIG. 54 illustrates the Service Access Control for new FAP connecting toFemtocell network in some embodiments.

FIG. 55 illustrates the Service Access Control for the FAP gettingredirected in Femtocell network in some embodiments.

FIG. 56 illustrates the Service Access Control for FAP registering inrestricted UMTS coverage area in some embodiments.

FIG. 57 illustrates the Service Access Control for Unauthorized UEaccessing authorized FAP in some embodiments.

FIG. 58 conceptually illustrates a computer system with which someembodiments are implemented.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the invention, numerousdetails, examples, and embodiments of the invention are set forth anddescribed. However, it will be clear and apparent to one skilled in theart that the invention is not limited to the embodiments set forth andthat the invention may be practiced without some of the specific detailsand examples discussed.

Throughout the following description, acronyms commonly used in thetelecommunications industry for wireless services are utilized alongwith acronyms specific to the present invention. A table of acronymsused in this application is included in Section XV.

Some embodiments are implemented in a communication system that includesa first wireless communication system and a second wirelesscommunication system that includes a Femtocell access point (FAP) and anetwork controller that can communicatively couple the FAP to the firstwireless communication system.

In some embodiments, the network controller can communicatively coupleto the first wireless communication system through a UTRAN Iu interface.In some embodiments, the FAP can communicatively couple to a userequipment using a short-range licensed wireless frequency.

Some embodiments provide a resource management method that determinesthat a user equipment (UE) has roved in a region serviced by the FAP.The FAP includes a generic access resource control (GA-RC) protocolsub-layer. The method creates a separate GA-RC state dedicated to the UEin the GA-RC protocol sub-layer. The method also sets the GA-RC statededicated to the UE to a deregistered state to indicate that the UE isnot registered to use the services of the second wireless communicationsystem.

Some embodiments provide method that determines whether a UE hasroved-out of the second communication system. The method receives aperiodic message at the FAP from the UE. When the FAP fails to receive apre-determined number of the periodic messages, the method sends aderegister message to the network controller over a unique connectionbetween the FAP and the network controller which is dedicated to the UEand also releases the dedicated connection.

Some embodiments provide a method of that releases resources after theloss of connectivity. The method sends a periodic message from the FAPto the network controller over a connection between the FAP and thenetwork controller to determine whether the connection is lost. When theFAP determines that the connection is lost, the FAP deregisters a userequipment (UE) that is communicatively coupled with the FAP and forcesthe UE to perform a cell reselection.

Some embodiments provide a method that registers a Femtocell accesspoint (FAP). The method sends a register request message that includes aregistration type from the FAP to the network controller. Theregistration type identifies the FAP as a device to be registered withthe network controller. When the register request message is acceptableby the network controller, the FAP receives a register accept message.

Some embodiments provide a method for performing discovery. The methodsends a discovery request message that includes a licensed wireless cellinformation to a provisioning network controller. The method receives adiscovery accept message at the FAP. The discovery accept messageincludes identification of a default network controller determined basedon the cell information. The discovery accept message is sent by theprovisioning network controller when the provisioning network controllerdetermines that the provisioning network controller can accept thediscovery request message.

Some embodiments provide a method of performing a user equipment (UE)registration. The method establishes a unique connection dedicated tothe UE between the FAP and the network controller. The method receives aregister request message at the network controller from the FAP throughthe dedicated connection.

Some embodiments provide a security control method. The method receivesa security mode command that includes a set of security keys and a setof security algorithms at the FAP from the network controller, the setof security keys and the set of security algorithms are received at thenetwork controller from the first wireless communication system. Themethod determines the integrity of a set of messages that are exchangedbetween the FAP and a user equipment (UE) that is communicativelycoupled to the FAP through an air interface by using the set of securitykeys and the set of security algorithms.

Some embodiments provide method of providing security. The methodestablishes a secure tunnel between the FAP and the network controller.The method communicatively couples the FAP and several user equipments(UEs) to the network controller by using the secure tunnel. The UEs arecommunicatively coupled to the FAP through an air interface.

Some embodiments provide a method of preventing theft of service. Themethod creates an authorized session that includes a session identityfor a first user equipment (UE). The session is for communicativelycoupling the first UE with the first wireless communication systemthrough the FAP. The first UE is recognized by the first wirelesscommunication system as an authorized UE to use the FAP. The methodrejects a request by the FAP to register a second UE when the identityof the second UE does not match any identity in the set of first UEidentities. The rejected request includes the session identity of theauthorized session and the identity of the second UE. The second UE isnot recognized by the first wireless communication system as anauthorized UE to use the FAP.

Several more detailed embodiments of the invention are described insections below. Specifically, Section I describes the overall integratedcommunication system in which some embodiments are incorporated. Thediscussion in Section I is followed by a discussion of the systemarchitecture of a Femtocell system in Section II. Next, Section IIIdescribes the protocol architecture of the Femtocell system. Section IVthen describes the resource management procedures of the Femtocellsystem in some embodiments. Next, Section V presents the mobilitymanagement functions of the Femtocell system in some embodiments.

Next, Section VI describes the call management procedures of theFemtocell system. This section is followed by Section VII whichdescribes the packet services of the Femtocell system in someembodiments. Error handling procedures are described in Section VIII.Lists of messages and information elements used in different embodimentsare provided in Section IX. Short Message Services support of theFemtocell system is described in Section X followed by the descriptionof the emergency services in Section XI.

The Femtocell system security functions are described in Section XII.This description is followed by Femtocell system service access controldiscussed in Section XIII. Next, Section XIV description of a computersystem with which some embodiments of the invention are implemented.Finally, Section XV lists the abbreviations used.

I. OVERALL SYSTEM

A. Integrated Communication Systems (ICS)

FIG. 1 illustrates an integrated communication system (ICS) architecture100 in accordance with some embodiments of the present invention. ICSarchitecture 100 enables user equipment (UE) 102 to access a voice anddata network 165 via either a licensed air interface 106 or an ICSaccess interface 110 through which components of the licensed wirelesscore network 165 are alternatively accessed. In some embodiments, acommunication session through either interface includes voice services,data services, or both.

The mobile core network 165 includes one or more Home Location Registers(HLRs) 150 and databases 145 for subscriber authentication andauthorization. Once authorized, the UE 102 may access the voice and dataservices of the mobile core network 165. In order to provide suchservices, the mobile core network 165 includes a mobile switching center(MSC) 160 for providing access to the circuit switched services (e.g.,voice and data). Packet switched services are provided for through aServing GPRS (General Packet Radio Service) Support Node (SGSN) 155 inconjunction with a gateway such as the Gateway GPRS Support Node (GGSN)157.

The SGSN 155 is typically responsible for delivering data packets fromand to the GGSN 157 and the user equipment within the geographicalservice area of the SGSN 155. Additionally, the SGSN 155 may performfunctionality such as mobility management, storing user profiles, andstoring location information. However, the actual interface from themobile core network 165 to various external data packet servicesnetworks (e.g., public Internet) is facilitated by the GGSN 157. As thedata packets originating from the user equipment typically are notstructured in the format with which to access the external datanetworks, it is the role of the GGSN 157 to act as the gateway into suchpacket services networks. In this manner, the GGSN 157 providesaddressing for data packets passing to and from the UE 102 and theexternal packet services networks (not shown). Moreover, as the userequipment of a licensed wireless network traverses multiple serviceregions and thus multiple SGSNs, it is the role of the GGSN 157 toprovide a static gateway into the external data networks.

In the illustrated embodiment, components common to a UMTS TerrestrialRadio Access Network (UTRAN), based cellular network that includesmultiple base stations referred to as Node Bs 180 (of which only one isshown for simplicity) that facilitate wireless communication servicesfor various user equipment 102 via respective licensed radio links 106(e.g., radio links employing radio frequencies within a licensedbandwidth). However, one of ordinary skill in the art will recognizethat in some embodiments, the licensed wireless network may includeother components such the GSM/EDGE Radio Access Network (GERAN). Anexample of a system using A and Gb interfaces to access GERAN is shownin FIG. 3 described further below.

The licensed wireless channel 106 may comprise any licensed wirelessservice having a defined UTRAN or GERAN interface protocol (e.g., Iu-csand Iu-ps interfaces for UTRAN or A and Gb interfaces for GERAN) for avoice/data network. The UTRAN 185 typically includes at least one Node B180 and a Radio Network Controller (RNC) 175 for managing the set ofNode Bs 180. Typically, the multiple Node Bs 180 are configured in acellular configuration (one per each cell) that covers a wide servicearea. A licensed wireless cell is sometimes referred to as a macro cellwhich is a logical term used to reference, e.g., the UMTS radio cell(i.e., 3G cell) under Node-B/RNC which is used to provide coveragetypically in the range of tens of kilometers. Also, the UTRAN or GERANis sometimes referred to as a macro network.

Each RNC 175 communicates with components of the core network 165through a standard radio network controller interface such as the Iu-csand Iu-ps interfaces depicted in FIG. 1. For example, a RNC 175communicates with MSC 160 via the UTRAN Iu-cs interface for circuitswitched services. Additionally, the RNC 175 communicates with SGSN 155via the UTRAN Iu-ps interface for packet switched services through GGSN157. Moreover, one of ordinary skill in the art will recognize that insome embodiments, other networks with other standard interfaces mayapply. For example, the RNC 175 in a GERAN network is replaced with aBase Station Controller (BSC) that communicates with the MSC 160 via anA interface for the circuit switched services and the BSC communicateswith the SGSN via a Gb interface of the GERAN network for packetswitched services.

In some embodiments of the ICS architecture, the user equipment 102 usethe services of the mobile core network (CN) 165 via a secondcommunication network facilitated by the ICS access interface 110 and aGeneric Access Network Controller (GANC) 120 (also referred to as aUniversal Network Controller or UNC).

In some embodiments, the voice and data services over the ICS accessinterface 110 are facilitated via an access point 114 communicativelycoupled to a broadband IP network 116. In some embodiments, the accesspoint 114 is a generic wireless access point that connects the userequipment 102 to the ICS network through an unlicensed wireless network118 created by the access point 114. In some other embodiments, theaccess point 114 is a Femtocell access point (FAP) 114 communicativelycoupled to a broadband IP network 116. The FAP facilitates short-rangelicensed wireless communication sessions 118 that operate independent ofthe licensed communication session 106. In some embodiments, the GANC,FAP, UE, and the area covered by the FAP are collectively referred to asa Femtocell System. A Femtocell spans a smaller area (typically few tensof meters) than a macro cell. In other words, the Femtocell is a microcell that has a range that is 100, 1000, or more times less than a macrocell. In case of the Femtocell system, the user equipment 102 connectsto the ICS network through a short-range licensed wireless networkcreated by the FAP 114. Signals from the FAP are then transmitted overthe broadband IP network 116.

The signaling from the UE 102 is passed over the ICS access interface110 to the GANC 120. After the GANC 120 performs authentication andauthorization of the subscriber, the GANC 120 communicates withcomponents of the mobile core network 165 using a radio networkcontroller interface that is the same or similar to the radio networkcontroller interface of the UTRAN described above, and includes a UTRANIu-cs interface for circuit switched services and a UTRAN Iu-psinterface for packet switched services (e.g., GPRS). In this manner, theGANC 120 uses the same or similar interfaces to the mobile core networkas a UTRAN Radio Access Network Subsystem (e.g., the Node B 180 and RNC175).

In some embodiments, the GANC 120 communicates with other systemcomponents of the ICS system through one or more of several otherinterfaces, which are (1) “Up”, (2) “Wm”, (3) “D′/Gr′”, (4) “Gn′”, and(5) “S1”. The “Up” interface is the standard interface for sessionmanagement between the UE 102 and the GANC 120. The “Wm” interface is astandardized interface between the GANC 120 and an Authorization,Authentication, and Accounting (AAA) Server 170 for authentication andauthorization of the UE 102 into the ICS. The “D′/Gr′” interface is thestandard interface between the AAA server 170 and the HLR 160.Optionally, some embodiments use the “Gn′” interface which is a modifiedinterface for direct communications with the data services gateway(e.g., GGSN) of the mobile core network. Some embodiments optionallyinclude the “S1” interface. In these embodiments, the “S1” interfaceprovides an authorization and authentication interface from the GANC 120to an AAA sever 140. In some embodiments, the AAA server 140 thatsupports the S1 interface and the AAA server 170 that supports Wminterface may be the same. More details of the S1 interface aredescribed in U.S. application Ser. No. 11/349,025, entitled “ServiceAccess Control Interface for an Unlicensed Wireless CommunicationSystem”, filed Feb. 6, 2006.

In some embodiments, the UE 102 must register with the GANC 120 prior toaccessing ICS services. Registration information of some embodimentsincludes a subscriber's International Mobile Subscriber Identity (IMSI),a Media Access Control (MAC) address, and a Service Set Identifier(SSID) of the serving access point as well as the cell identity from theGSM or UTRAN cell upon which the UE 102 is already camped (a UE iscamped on a cell when the UE has completed the cellselection/reselection process and has chosen a cell; the UE monitorssystem information and, in most cases, paging information). In someembodiments, the GANC 120 may pass this information to the AAA server140 to authenticate the subscriber and determine the services (e.g.,voice and data) available to the subscriber. If approved by the AAAserver 140 for access, the GANC 120 will permit the UE 102 to accessvoice and data services of the ICS system.

These circuit switched and packet switched services are seamlesslyprovided by the ICS to the UE 102 through the various interfacesdescribed above. In some embodiments, when data services are requestedby the UE 102, the ICS uses the optional Gn′ interface for directlycommunicating with a GGSN 157. The Gn′ interface allows the GANC 120 toavoid the overhead and latency associated with communicating with theSGSN 155 over the Iu-ps interface of the UTRAN or the Gb interface ofthe GSM core networks prior to reaching the GGSN 157.

B. Applications of ICS

An ICS provides scalable and secure interfaces into the core servicenetwork of mobile communication systems. FIG. 2 illustrates severalapplications of an ICS in some embodiments. As shown, homes, offices,hot spots, hotels, and other public and private places 205 are connectedto one or more network controllers 210 (such as the GANC 120 shown inFIG. 1) through the Internet 215. The network controllers in turnconnect to the mobile core network 220 (such as the core network 165shown in FIG. 1).

FIG. 2 also shows several user equipments. These user equipments arejust examples of user equipments that can be used for each application.Although in most examples only one of each type of user equipments isshown, one of ordinary skill in the art would realize that other type ofuser equipments can be used in these examples without deviating from theteachings of the invention. Also, although only one of each type ofaccess points, user equipment, or network controllers are shown, manysuch access points, user equipments, or network controllers may beemployed in FIG. 2. For instance, an access point may be connected toseveral user equipment, a network controller may be connected to severalaccess points, and several network controllers may be connected to thecore network. The following sub-sections provide several examples ofservices that can be provided by an ICS.

1. Wi-Fi

A Wi-Fi access point 230 enables a dual-mode cellular/Wi-Fi UEs 260-265to receive high-performance, low-cost mobile services when in range of ahome, office, or public Wi-Fi network. With dual-mode UEs, subscriberscan roam and handover between licensed wireless communication system andWi-Fi access and receive a consistent set of services as they transitionbetween networks.

2. Femtocells

A Femtocell enables user equipments, such as standard mobile stations270 and wireless enabled computers 275 shown, to receive low costservices using a short-range licensed wireless communication sessionsthrough a FAP 235.

3. Terminal Adaptors

Terminal adaptors 240 allow incorporating fixed-terminal devices such astelephones 245, Faxes 250, and other equipments that are not wirelessenabled within the ICS. As far as the subscriber is concerned, theservice behaves as a standard analog fixed telephone line. The serviceis delivered in a manner similar to other fixed line VoIP services,where a UE is connected to the subscriber's existing broadband (e.g.,Internet) service.

4. WiMAX

Some licensed wireless communication system operators are investigatingdeployment of WiMAX networks in parallel with their existing cellularnetworks. A dual mode cellular/WiMAX UE 255 enables a subscriber toseamlessly transition between a cellular network and such a WiMAXnetwork through a WiMax access point 290.

5. SoftMobiles

Connecting laptops 280 to broadband access at hotels and Wi-Fi hot spotshas become popular, particularly for international business travelers.In addition, many travelers are beginning to utilize their laptops andbroadband connections for the purpose of voice communications. Ratherthan using mobile phones to make calls and pay significant roaming fees,they utilize SoftMobiles (or SoftPhones) and VoIP services when makinglong distance calls.

To use a SoftMobile service, a subscriber would place a USB memory stick285 with an embedded SIM into a USB port of their laptop 280. ASoftMobile client would automatically launch and connect over IP to themobile service provider. From that point on, the subscriber would beable to make and receive mobile calls as if she was in her home callingarea.

Several examples of Integrated Communication Systems (ICS) are given inthe following sub-sections. A person of ordinary skill in the art wouldrealize that the teachings in these examples can be readily combined.For instance, an ICS can be an IP based system and have an A/Gbinterface towards the core network while another ICS can have a similarIP based system with an Iu interface towards the core network.

C. Integrated Systems with A/Gb and/or Iu Interfaces Towards the CoreNetwork

FIG. 3 illustrates the A/Gb-mode Generic Access Network (GAN) functionalarchitecture of some embodiments. The GAN includes one or more GenericAccess Network Controllers (GANC) 310 and one or more generic IP accessnetworks 315. One or more UEs 305 (one is shown for simplicity) canconnect to a GANC 310 through a generic IP access network 315. The GANC310 has the capability to appear to the core network 325 as a GSM/EDGERadio Access Network (GERAN) Base Station Controller (BSC). The GANC 310includes a Security Gateway (SeGW) 320 that terminates secure remoteaccess tunnels from the UE 305, providing mutual authentication,encryption and data integrity for signaling, voice and data traffic.

The generic IP access network 315 provides connectivity between the UE305 and the GANC 310. The IP transport connection extends from the GANC310 to the UE 305. A single interface, the Up interface, is definedbetween the GANC 310 and the UE 305.

The GAN co-exists with the GERAN and maintains the interconnections withthe Core Network (CN) 325 via the standardized interfaces defined forGERAN. These standardized interfaces include the A interface to MobileSwitching Center (MSC) 330 for circuit switched services, Gb interfaceto Serving GPRS Support Node (SGSN) 335 for packet switched services, Lbinterface to Serving Mobile Location Center (SMLC) 350 for supportinglocation services, and an interface to Cell Broadcast Center (CBC) 355for supporting cell broadcast services. The transaction control (e.g.Connection Management, CC, and Session Management, SM) and user servicesare provided by the core network (e.g. MSC/VLR and the SGSN/GGSN).

As shown, the SeGW 320 is connected to a AAA server 340 over the Wminterface. The AAA server 340 is used to authenticate the UE 305 when itsets up a secure tunnel. Some embodiments require only a subset of theWm functionalities for the GAN application. In these embodiments, as aminimum the GANC-SeGW shall support the Wm authentication procedures.

FIG. 4 illustrates the Iu-mode Generic Access Network (GAN) functionalarchitecture of some embodiments. The GAN includes one or more GenericAccess Network Controllers (GANC) 410 and one or more generic IP accessnetworks 415. One or more UEs 405 (one is shown for simplicity) can beconnected to a GANC 410 through a generic IP access network 415. Incomparison with the GANC 310, the GANC 410 has the capability to appearto the core network 425 as a UMTS Terrestrial Radio Access Network(UTRAN) Radio Network Controller (RNC). In some embodiments, the GANChas the expanded capability of supporting both the Iu and A/Gbinterfaces to concurrently support both Iu-mode and A/Gb-mode UEs.Similar to the GANC 310, the GANC 410 includes a Security Gateway (SeGW)420 that terminates secure remote access tunnels from the UE 405,providing mutual authentication, encryption and data integrity forsignaling, voice and data traffic.

The generic IP access network 415 provides connectivity between the UE405 and the GANC 410. The IP transport connection extends from the GANC410 to the UE 405. A single interface, the Up interface, is definedbetween the GANC 410 and the UE 405. Functionality is added to thisinterface, over the UP interface shown in FIG. 3, to support the Iu-modeGAN service.

The GAN co-exists with the UTRAN and maintains the interconnections withthe Core Network (CN) 425 via the standardized interfaces defined forUTRAN. These standardized interfaces include the Iu-cs interface toMobile Switching Center (MSC) 430 for circuit switched services, Iu-psinterface to Serving GPRS Support Node (SGSN) 435 for packet switchedservices, Iu-pc interface to Serving Mobile Location Center (SMLC) 450for supporting location services, and Iu-bc interface to Cell BroadcastCenter (CBC) 455 for supporting cell broadcast services. The transactioncontrol (e.g. Connection Management, CC, and Session Management, SM) anduser services are provided by the core network (e.g. MSC/VLR and theSGSN/GGSN).

As shown, the SeGW 420 is connected to a AAA server 440 over the Wminterface. The AAA server 440 is used to authenticate the UE 405 when itsets up a secure tunnel. Some embodiments require only a subset of theWm functionalities for the Iu mode GAN application. In theseembodiments, as a minimum the GANC-SeGW shall support the Wmauthentication procedures.

II. FEMTOCELL SYSTEM ARCHITECTURE

FIG. 5 illustrates the Femtocell system functional architecture of someembodiments. As shown, many components of the system shown in FIG. 5 aresimilar to components of FIG. 4. In addition, the Femtocell systemincludes a Femtocell Access Point (FAP) 560 which communicativelycouples the UE 505 to the GANC 510 through the Generic IP Access Network515. The interface between the UE 505 and the FAP 560 is referred to asthe Uu interface in this disclosure. The UE 505 and the FAP 560communicate through a short-range wireless air interface using licensedwireless frequencies. The GANC 510 is an enhanced version of the GANC410 shown in FIG. 4. The Security Gateway (SeGW) 520 component of theGANC 510 terminates secure remote access tunnels from the FAP 560,providing mutual authentication, encryption and data integrity forsignaling, voice and data traffic.

The Femtocell Access Point (AP) Management System (AMS) 570 is used tomanage a large number of FAPs. The AMS 570 functions includeconfiguration, failure management, diagnostics, monitoring and softwareupgrades. The interface between the AMS 570 and the FAP 560 is referredto as the S3 interface. The S3 interface enables secure access toFemtocell access point management services for FAPs. All communicationbetween the FAPs and AMS is exchanged via the Femtocell secure tunnelthat is established between the FAP and SeGW 520. As shown, the AMS 570accesses to the AP/subscriber databases (Femtocell DB) 575 whichprovides centralized data storage facility for Femtocell AP (i.e., theFAP) and subscriber information. Multiple Femtocell system elements mayaccess Femtocell DB via AAA server.

The IP Network Controller (INC) 565 component of the GANC 510 interfaceswith the AAA/proxy server 540 through the S1 interface for provisioningof the FAP related information and service access control. As shown inFIG. 5, the AAA/proxy server 540 also interfaces with the AP/subscriberdatabases 575.

A. ATM and IP Based Architectures

In some embodiments, the Femtocell system uses Asynchronous TransferMode (ATM) based Iu (Iu-cs and Iu-ps) interfaces towards the CN. In someembodiments, the Femtocell system architecture can also support an IPbased Iu (Iu-cs and Iu-ps) interface towards the CN.

A person of ordinary skill in the art would realize that the sameexamples can be readily applied to other types of ICS. For instance,these examples can be used when the ICS access interface 110 (shown inFIG. 1) uses unlicensed frequencies (instead of Femtocell's licensedfrequencies), the access point 114 is a generic WiFi access point(instead of a FAP), etc. Also, a person of ordinary skill in the artwould realize that the same examples can be readily implemented usingA/Gb interfaces (described above) instead of Iu interfaces.

FIG. 6 illustrates the basic elements of the Femtocell systemarchitecture with Asynchronous Transfer Mode (ATM) based Iu (Iu-cs andIu-ps) interfaces towards the CN in some embodiments. These elementsinclude the user equipment (UE) 605, the FAP 610, and the Generic AccessNetwork Controller (GANC) 615, and the AMS 670.

For simplicity, only one UE and one FAP are shown. However, each GANCcan support multiple FAPs and each FAP in turn can support multiple UEs.As shown, the GANC 615 includes an IP Network Controller (INC) 625, aGANC Security Gateway (SeGW) 630, a GANC Signaling Gateway 635, a GANCMedia Gateway (MGW) 640, an ATM Gateway (645). Elements of the Femtocellare described further below.

FIG. 7 illustrates the basic elements of the Femtocell systemarchitecture with an IP based Iu (Iu-cs and Iu-ps) interface towards theCN in some embodiments. For simplicity, only one UE and one FAP areshown. However, each GANC can support multiple FAPs and each FAP in turncan support multiple UEs. This option eliminates the need for the GANCSignaling gateway 635 and also the ATM gateway 645. Optionally for IPbased Iu interface, the GANC Media Gateway 640 can also be eliminated ifthe R4 MGW 705 in the CN can support termination of voice data i.e. RTPframes as defined in “Real-Time Transport Protocol (RTP) Payload Formatand File Storage Format for the Adaptive Multi-Rate (AMR) and AdaptiveMulti-Rate Wideband (AMR-WB) Audio Codecs”, IETF RFC 3267, hereinafter“RFC 3267”.

Also shown in FIGS. 6 and 7 are components of the licensed wirelesscommunication systems. These components are 3G MSC 650, 3G SGSN 655, andother Core Network System (shown together) 665. The 3G MSC 650 providesa standard Iu-cs interface towards the GANC. Another alternative for theMSC is shown in FIG. 7. As shown, the MSC 750 is split up into a MSS(MSC Server) 775 for Iu-cs based signaling and MGW 780 for the bearerpath. R4 MSC 750 is a release 4 version of a 3G MSC with a differentarchitecture i.e. R4 MSC is split into MSS for control traffic and a MGWfor handling the bearer. A similar MSC can be used for the ATMarchitecture of FIG. 6. Both architectures shown in FIGS. 6 and 7 arealso adaptable to use any future versions of the MSC.

The 3G SGSN 655 provides packet services (PS) via the standard Iu-psinterface. The SGSN connects to the INC 625 for signaling and to theSeGW 630 for PS data. The AAA server 660 communicates with the SeGW 630and supports the EAP-AKA and EAP-SIM procedures used in IKEv2 over theWm interface and includes a MAP interface to the HLR/AuC. This systemalso supports the enhanced service access control functions over the S1interface.

For simplicity, in several diagrams throughout the present application,only the INC component of the GANC is shown. Also, whenever the INC isthe relevant component of the GANC, references to the INC and GANC areused interchangeably.

B. Functional Entities

1. User Equipment (UE)

The UE includes the functions that are required to access the Iu-modeGAN. In some embodiments, the UE additionally includes the functionsthat are required to access the A/Gb-mode GAN. In some embodiments, theUser Equipment (UE) is a dual mode (e.g., GSM and unlicensed radios)handset device with capability to switch between the two modes. The userequipment can support either Bluetooth® or IEEE 802.11 protocols. Insome embodiments, the UE supports an IP interface to the access point.In these embodiments, the IP connection from the GANC extends all theway to the UE. In some other embodiments, the User Equipment (UE) is astandard 3G handset device operating over licensed spectrum of theprovider.

In some embodiments, the user equipment includes a cellular telephone,smart phone, personal digital assistant, or computer equipped with asubscriber identity mobile (SIM) card for communicating over thelicensed or unlicensed wireless networks. Moreover, in some embodimentsthe computer equipped with the SIM card communicates through a wiredcommunication network.

Alternatively, in some embodiments the user equipment includes a fixedwireless device providing a set of terminal adapter functions forconnecting Integrated Services Digital Network (ISDN), SessionInitiation Protocol (SIP), or Plain Old Telephone Service (POTS)terminals to the ICS. Application of the present invention to this typeof device enables the wireless service provider to offer the so-calledlandline replacement service to users, even for user locations notsufficiently covered by the licensed wireless network. Moreover, someembodiments of the terminal adapters are fixed wired devices forconnecting ISDN, SIP, or POTS terminals to a different communicationnetwork (e.g., IP network) though alternate embodiments of the terminaladapters provide wireless equivalent functionality for connectingthrough unlicensed or licensed wireless networks.

2. Femtocell Access Point (FAP)

The FAP is a licensed access point which offers a standard radiointerface (Uu) for UE connectivity. The FAP provides radio accessnetwork connectivity for the UE using a modified version of the standardGAN interface (Up). In some embodiments, the FAP is equipped with eithera standard 3G USIM or a 2G SIM.

In accordance with some embodiments, the FAP 610 will be located in afixed structure, such as a home or an office building. In someembodiments, the service area of the FAP includes an indoor portion of abuilding, although it will be understood that the service area mayinclude an outdoor portion of a building or campus.

3. Generic Access Network Controller (GANC)

The GANC 510 is an enhanced version of the GANC defined in “Genericaccess to the A/Gb interface; Stage 2”, 3GPP TS 43.318 standard,hereinafter “TS 43.318 standard”. The GANC appears to the core networkas a UTRAN Radio Network Controller (RNC). The GANC includes a SecurityGateway (SeGW) 520 and IP Network Controller (INC) 565. In someembodiments (not shown in FIG. 5), the GANC also includes GANC SignalingGateway 635, a GANC Media Gateway (MGW) 640, and/or an ATM Gateway(645).

The SeGW 520 provides functions that are defined in TS 43.318 standardand “Generic access to the A/Gb interface; Stage 3”, 3GPP TS 44.318standard. The SeGW terminates secure access tunnels from the FAP,providing mutual authentication, encryption and data integrity forsignaling, voice and data traffic. The SeGW 520 is required to supportEAP-SIM and EAP-AKA authentication for the FAP 560.

The INC 565 is the kay GANC element. In some embodiments, the INC isfront-ended with a load balancing router/switch subsystem which connectsthe INC to the other GAN systems; e.g., GANC security gateways, local orremote management systems, etc.

The GANC MGW 640 provides the inter-working function between the Upinterface and the Iu-CS user plane. The GANC MGW would provideinter-working between RFC 3267 based frames received over the Upinterface and Iu-UP frames towards the CN. The GANC Signaling GW 635provides protocol conversion between SIGTRAN interface towards the INCand the ATM based Iu-cs interface towards the CN. The ATM GW 645provides ATM/IP gateway functionality, primarily routing Iu-ps userplane packets between the SeGW (IP interface) and CN (AAL5 based ATMinterface).

4. Broadband IP Network

The Broadband IP Network 515 represents all the elements thatcollectively, support IP connectivity between the GANC SeGW 520 functionand the FAP 560. This includes: (1) Other Customer premise equipment(e.g., DSL/cable modem, WLAN switch, residential gateways/routers,switches, hubs, WLAN access points), (2) Network systems specific to thebroadband access technology (e.g., DSLAM or CMTS), (3) ISP IP networksystems (edge routers, core routers, firewalls), (4) Wireless serviceprovider (WSP) IP network systems (edge routers, core routers,firewalls), and (5) Network address translation (NAT) functions, eitherstandalone or integrated into one or more of the above systems.

5. AP Management System (AMS)

The AMS 570 is used to manage a large number of FAPs 560 includingconfiguration, failure management, diagnostics, monitoring and softwareupgrades. The access to AMS functionality is provided over secureinterface via the GANC SeGW 520.

Some embodiments of the above mentioned devices, such as the userequipment, FAP, or GANC, include electronic components, such asmicroprocessors and memory (not shown), that store computer programinstructions (such as instructions for executing wireless protocols formanaging voice and data services) in a machine-readable orcomputer-readable medium as further described below in the sectionlabeled “Computer System”. Examples of machine-readable media orcomputer-readable media include, but are not limited to magnetic mediasuch as hard disks, memory modules, magnetic tape, optical media such asCD-ROMS and holographic devices, magneto-optical media such as opticaldisks, and hardware devices that are specially configured to store andexecute program code, such as application specific integrated circuits(ASICs), programmable logic devices (PLDs), ROM, and RAM devices.Examples of computer programs or computer code include machine code,such as produced by a compiler, and files including higher-level codethat are executed by a computer, an electronic component, or amicroprocessor using an interpreter.

III. FEMTOCELL PROTOCOL ARCHITECTURE A. CS Domain Control PlaneArchitecture

The GAN Femtocell architecture of some embodiments in support of the CSDomain control plane is illustrated in FIG. 8. The figure showsdifferent protocol layers for the UE 805, FAP 810, Generic IP Network815, SeGW 820, INC 825, and MSC 830. FIG. 8 also shows the threeinterfaces Uu 840, Up 845 and Iu-cs 850.

1. Up Interface for the CS Domain Control Plane

The main features of the Up interface 845 for the CS domain controlplane are as follows. The underlying Access Layers 846 and Transport IPlayer 848 provide the generic connectivity between the FAP 810 and theGANC (which includes SeGW 820 and INC 825). The IPSec encapsulationsecurity payload (ESP) layer 850 provides encryption and data integrity.

The TCP 852 provides reliable transport for the GA-RC 854 between FAP810 and GANC and is transported using the Remote IP layer 856. The GA-RC854 manages the IP connection, including the Femtocell registrationprocedures.

The GA-CSR 858 protocol performs functionality equivalent to the UTRANRRC protocol, using the underlying connection managed by the GA-RC 854.Protocols, such as MM 860 and above, are carried transparently betweenthe UE 805 and MSC 830. The GANC terminates the GA-CSR 858 protocol andinter-works it to the Iu-cs 850 interface using Radio Access NetworkApplication Part (RANAP) 862 messaging.

The Remote IP layer 856 is the ‘inner’ IP layer for IPSec tunnel modeand is used by the FAP 810 to be addressed by the INC 825. Remote IPlayer 856 is configured during the IPSec connection establishment. Insome embodiments, the Iu-cs signaling transport layers 870 are per“UTRAN Iu interface signalling transport”, 3GPP TS 25.412 standard,hereinafter “TS 25.412”.

B. CS Domain User Plane Architecture

The GAN Femtocell protocol architecture of some embodiments in supportof the CS domain user plane is illustrated in FIG. 9. The figure showsdifferent protocol layers for the UE 905, FAP 910, Generic IP Network915, SeGW 920, Media GW 925, and MSC 930. FIG. 9 also shows the threeinterfaces Uu 935, Up 940, and Iu-cs 945.

The main features of the CS domain user plane are as follows. Theunderlying Access Layers 950 and Transport IP layer 952 provide thegeneric connectivity between the FAP 910 and the GANC. The IPSec layer954 provides encryption and data integrity.

The FAP 910 frames the CS user data 956 (received over the airinterface) into RFC 3267 defined frames. RFC 3267 user data 958 istransported over the Up interface to the GANC Media GW 925. The GANCMedia GW 925 will provide inter-working function 960 with Iu-UP (e.g.,Support Mode) towards the CN. In some embodiments, Iu-UP uses ATM as atransport mechanism between the CN and the GANC Media GW 925. In someembodiments, Iu-Up uses IP as a transport mechanism between the CN andthe GANC Media GW 925. In some embodiments, the CS domain user planearchitecture supports AMR codec, as specified in “AMR speech codec;General description”, 3GPP TS 26.071 standard with support for othercodec being optional. In some embodiments, the Iu-cs Data transportlayers 970 are per TS 25.414.

C. PS Domain Control Plane Architecture

The GAN Femtocell architecture of some embodiments in support of the PSDomain Control Plane is illustrated in FIG. 10. The figure showsdifferent protocol layers for the UE 1005, FAP 1010, Generic IP Network1015, SeGW 1020, INC 1025, and SGSN 1030. FIG. 10 also shows the threeinterfaces Uu 1040, Up 1045, and Iu-ps 1050.

The main features of the Up interface 1045 for the PS domain controlplane are as follows. The underlying Access Layers 1052 and Transport IPlayer 1054 provide the generic connectivity between the FAP 1010 and theGANC. The IPSec layer 1056 provides encryption and data integrity.

TCP 1058 provides reliable transport for the GA-PSR 1060 signalingmessages between FAP 1010 and GANC. The GA-RC 1062 manages the IPconnection, including the Femtocell registration procedures. The GA-PSR1060 protocol performs functionality equivalent to the UTRAN RRCprotocol.

Upper layer protocols 1064, such as for GMM, SM and SMS, are carriedtransparently between the UE 1005 and CN. The GANC terminates the GA-PSR1060 protocol and inter-works it to the Iu-ps interface 1050 using RANAP1070. In some embodiments, the Iu-ps signaling transport layers 1080 areper TS 25.412.

D. PS Domain User Plane Architecture

FIG. 11 illustrates the GAN Femtocell architecture for the PS DomainUser Plane of some embodiments. The figure shows different protocollayers for the UE 1105, FAP 1110, Generic IP Network 1115, SeGW 1120,Packet Gateway (Packet GW) 1125, and SGSN 1130. FIG. 11 also shows thethree interfaces Uu 1135, Up 1140, and Iu-ps 1145.

The main features of the Up interface 1140 for PS domain user plane areas follows. The underlying Access Layers 1150 and Transport IP layer1155 provides the generic connectivity between the FAP 1110 and theGANC. The IPSec layer 1160 provides encryption and data integrity. TheGTP-U 1170 protocol operates between the FAP 1110 and the SGSN 1130transporting the upper layer payload (i.e. user plane data) across theUp 1140 and Iu-ps interfaces 1145.

The packet GW 1125 provides either ATM GW functionality for ATMtransport or IP GW functionality for IP transport. In some embodiment,the Packet GW 1125 functionality is combined in the SeGW 1120.Additionally, in some embodiments, the Packet GW provides a GTP-U proxyfunctionality as well, where the GTP-U is optionally terminated in thePacket GW 1125 on either side. In the embodiments that the Packet GW1125 provides ATM GW functionality, the packet GW 1125 providestransport layer conversion between IP (towards the FAP 1110) and ATM(towards the CN). User data 1180 is carried transparently between the UE1105 and CN. In some embodiments, the Iu-ps Data transport layers 1180are per TS 25.414.

E. Alternative Embodiments

In some embodiments, instead of using separate CSR and PSR protocols forcommunication between the FAP and the GANC, as described in thisSpecification, a single protocol, Generic Access Radio Resource Control(GA-RRC) is used. In these embodiments, the GA-CSR 858 (shown in FIG. 8)and GA-PSR 1060 (shown in FIG. 10) protocol layers are replaced with oneprotocol layer GA-RRC. Details of the GA-RRC protocol architecture andmessaging are further described in the U.S. patent application Ser. No.11/778,040, entitled “Generic Access to the Iu Interface”, filed on Jul.14, 2007. This Application is incorporated herein by reference. One ofordinary skill in the art would be able to apply the disclosure of thepresent application regarding the GA-CSR and GA-PSR protocols to theGA-RRC protocol.

IV. RESOURCE MANAGEMENT

A. GA-RC (Generic Access Resource Control)

The GA-RC protocol provides a resource management layer, with thefollowing functions. (1) Discovery and registration with GANC, (2)Registration update with GANC, (3) Application level keep-alive withGANC, and (4) Support for identification of the FAP being used forFemtocell access.

1. States of the GA-RC Sub-Layer

FIG. 12 illustrates different states of the GA-RC sub-layer in the FAPin some embodiments. As shown, the GA-RC sub-layer in the FAP can be inone of two states: GA-RC-DEREGISTERED 1205 or GA-RC-REGISTERED 1210.

The FAP creates and maintains a separate state for the GA-RC sub-layerfor each device it registers. For instance, if the FAP registers threeUEs, the FAP creates and maintains three separate GA-RC sub-layers forthese three UEs. Also, the FAP supports registration for two types ofdevices i.e. the FAP and the UE. Based on the type of device, thefunctionality of the GA-RC sub-layer can vary.

a) GA-RC Sub-Layer for Device Type FAP

For the FAP device type, the GA-RC sub-layer is in theGA-RC-DEREGISTERED state 1205 upon power-up of the FAP. In this state,the FAP has not registered successfully with the GANC. The FAP mayinitiate the Registration procedure when in the GA-RC-DEREGISTERED state1205. The FAP returns to GA-RC-DEREGISTERED state 1205 on loss of TCP orIPSec connection or on execution of the De-registration procedure. Upontransition to GA-RC-DEREGISTERED state 1205, the FAP must trigger animplicit deregistration all the UEs currently camped on the FAP.

In the GA-RC-REGISTERED state 1210, the FAP is registered with theServing GANC. The FAP has an IPSec tunnel and a TCP connectionestablished to the Serving GANC through which the FAP may exchangeGA-RC, GA-CSR and GA-PSR signaling messages with the GANC. While the FAPremains in the GA-RC-REGISTERED state 1210 it performs application levelkeep-alive with the GANC.

b) GA-RC Sub-Layer for Device Type UE

For the UE device type, the GA-RC sub-layer in the FAP (for each UE) isin the GA-RC-DEREGISTERED state 1205 upon UE rove-in and creation of asubsequent TCP connection between the FAP and the GANC. In this state,the UE has not been registered successfully (by the FAP) with the GANC.The FAP may initiate the Registration procedure when UE specific GA-RCsub-layer is in the GA-RC-DEREGISTERED state 1205. The GA-RC sub-layerreturns to GA-RC-DEREGISTERED state 1205 on loss of TCP or IPSecconnection or on execution of the De-registration procedure. Upon lossof TCP connection, FAP may attempt to re-establish the corresponding TCPsession and perform the synchronization procedure. A failure tosuccessfully re-establish the TCP session will result in GA-RC layertransitioning to GA-RC-DEREGISTERED state 1205. The GA-RC sub-layer forUE can also transition to the GA-RC-DEREGISTERED state 1205 if thecorresponding GA-RC sub-layer for the FAP is in GA-RC-DEREGISTERED state1205.

In the GA-RC-REGISTERED state 1210, the UE has been registeredsuccessfully (by the FAP) with the Serving GANC. The FAP has a sharedIPSec tunnel and a new TCP connection established to the Serving GANCthrough which the FAP may exchange GA-RC, GA-CSR and GA-PSR signalingmessages (for each registered UE) with the GANC. For each of the UEdevice types, the FAP will perform an application level keep-alive withthe GANC on the corresponding TCP session.

In the GA-RC-REGISTERED state, the UE is camped on the Femtocell and mayeither be idle or the UE may be active in the Femtocell (e.g., a RRCconnection may have been established). In some embodiments, an idle UEis a UE that is not currently engaged in a voice or data communication.

B. GA-CSR (Generic Access Circuit Switched Resources)

The GA-CSR protocol provides a circuit switched services resourcemanagement layer which supports the following functions: (1) setup oftransport channels for CS traffic between the FAP and GANC, (2) directtransfer of NAS messages between the UE (or the FAP if the FAP supportslocal services) and the core network, and (3) other functions such as CSpaging and security configuration.

1. States of the GA-CSR Sub-Layer

FIG. 13 illustrates the state diagram in some embodiments for GA-CSR inthe FAP for each UE. As shown, the GA-CSR sub-layer in the FAP (for eachUE) can be in two states: GA-CSR-IDLE 1305 or GA-CSR-CONNECTED 1310.

The GA-CSR state for each UE enters the GA-CSR-IDLE state 1305 uponrove-in to the FAP and successful registration of the UE by the FAP withthe Serving GANC. This switch may occur only when the GA-RC state forthe UE is in the GA-RC-REGISTERED state 1210.

The UE GA-CSR moves from the GA-CSR-IDLE state 1305 to theGA-CSR-CONNECTED state 1310 when the GA-CSR connection is establishedand returns to GA-CSR-IDLE state 1305 when the GA-CSR connection isreleased. Upon GA-CSR connection release, an indication that nodedicated CS resources exist is passed to the upper layers.

A GA-CSR connection for each UE is typically established by the FAP whenupper layers messages (NAS layer) for the specific UE need to beexchanged with the network. The GA-CSR connection release can betriggered by the GANC or the FAP. If a FAP supports local services(Terminal Adaptor functionality) using the FAP SIM, there would besimilar GA-CSR state for the FAP.

C. GA-PSR (Generic Access Packet Switched Resources)

The GA-PSR protocol provides a packet switched services resourcemanagement layer which supports the following functions: (1) setup oftransport channels for PS traffic between the FAP (for each UE) andnetwork, (2) direct transfer of NAS messages between the UE and the PScore network, (3) transfer of GPRS user plane data, and (4) otherfunctions such as PS paging and security configuration.

1. States of the GA-PSR Sub-Layer

FIG. 14 illustrates the state diagram in some embodiments for GA-PSR inthe FAP for each UE. As shown, the GA-PSR sub-layer for each UE can bein two states: GA-PSR-IDLE 1405 or GA-PSR-CONNECTED 1410.

The GA-PSR state for each UE enters the GA-PSR-IDLE state 1405 uponrove-in to the FAP and successful registration of the UE by the FAP withthe Serving GANC. This switch may occur only when the GA-RC state forthe UE is in the GA-RC-REGISTERED state 1210.

The UE GA-PSR moves from the GA-PSR-IDLE state to the GA-PSR-CONNECTEDstate 1410 when the GA-PSR connection is established and returns toGA-PSR-IDLE state 1405 when the GA-PSR connection is released. UponGA-PSR connection release, an indication that no dedicated PS resourcesexist is passed to the upper layers. A GA-PSR connection for each UE istypically established by the FAP when upper layers messages (NAS layer)for the specific UE need to be exchanged with the network. The GA-PSRconnection release can be triggered by the GANC or the FAP.

The GA-PSR Transport Channel (GA-PSR TC) provides the associationbetween the FAP (for each UE) and GANC for the transport of PS user dataover the Up interface. It is further described in “GA-PSR TransportChannel Management Procedures” Section, below. If a FAP supports localservices (Terminal Adaptor functionality) using the FAP SIM, there wouldbe similar GA-PSR state and GA-PSR TC for the FAP.

D. GA-CSR and GA-PSR Connection Handling

The GA-CSR and GA-PSR connections are logical connections between theFAP and the GANC for the CS and PS domain respectively. The GA-CSR (orthe GA-PSR) connection is established when the upper layers in the FAPrequest the establishment of a CS (or PS) domain signaling connectionand the corresponding GA-CSR (or GA-PSR) is in GA-CSR-IDLE (orGA-PSR-IDLE) state, i.e. no GA-CSR (or GA-PSR) connection exists betweenthe FAP and GANC for the specific UE. In some embodiments, the upperlayer in the FAP requests the establishment of GA-CSR (or the GA-PSR)connection, when the FAP receives a corresponding higher layer (i.e. NASlayer) message over the air interface (i.e. over the RRC connection) forthe specific UE. In some embodiments, between the UE and the FAP, asingle RRC connection is utilized for both CS and PS domain.

When a successful response is received from the network, GA-CSR (orGA-PSR) replies to the upper layer that the CS (or PS) domain signalinghas been established and enters the corresponding connected mode (i.e.,the GA-CSR-CONNECTED or GA-PSR-CONNECTED state). The upper layers havethen the possibility to request transmission of a NAS messages for CS(or PS) services to the network over the corresponding GA-CSR (orGA-PSR) connection.

1. FAP Initiated GA-CSR Connection Establishment

FIG. 15 illustrates successful establishment of the GA-CSR connectionwhen initiated by the FAP 1505 in some embodiments. As shown, the FAP1505 initiates GA-CSR connection establishment by sending (in Step 1)the GA-CSR REQUEST message to the INC 1510. This message includes theEstablishment Cause indicating the reason for GA-CSR connectionestablishment.

INC 1510 signals the successful response to the FAP 1505 by sending (inStep 2) the GA-CSR REQUEST ACCEPT and the FAP 1505 enters theGA-CSR-CONNECTED state. Alternatively, the INC 1510 may return (in Step3) a GA-CSR REQUEST REJECT indicating the reject cause. As shown, MSC1515 plays no role in the FAP initiated GA-CSR connection establishment.

2. GA-CSR Connection Release

FIG. 16 shows release of the logical GA-CSR connection between the FAP1605 and the INC 1610 in some embodiments. As shown, the MSC 1615indicates (in Step 1) to the INC 1610 to release the CS resources (bothcontrol and user plane resources) allocated to the FAP 1605, via the IuRelease Command message. The INC 1610 confirms (in Step 2) resourcerelease to MSC 1615 using the Iu Release Complete message.

The INC 1610 commands (in Step 3) the FAP 1605 to release resources forthe specific UE connection, using the GA-CSR RELEASE message. The FAP1605 confirms (in Step 4) resource release to the INC 1610 using theGA-CSR RELEASE COMPLETE message and the GA-CSR state in the FAP 1605changes to GA-CSR-IDLE.

3. FAP Initiated GA-PSR Connection Establishment

FIG. 17 shows successful establishment of the GA-PSR Connection wheninitiated by the FAP 1705 in some embodiments. As shown, the FAP 1705initiates GA-PSR connection establishment by sending (in Step 1) theGA-PSR REQUEST message to the INC 1710. This message includes theEstablishment Cause indicating the reason for GA-PSR connectionestablishment.

The INC 1710 signals the successful response to the FAP 1705 by sendingthe GA-PSR REQUEST ACCEPT and the FAP 1705 enters the GA-PSR-CONNECTEDstate. Alternatively, the INC 1710 may return (in Step 3) a GA-PSRREQUEST REJECT indicating the reject cause. As shown, SGSN 1715 plays norole in the FAP initiated GA-CSR connection establishment.

4. GA-PSR Connection Release

FIG. 18 illustrates release of the logical GA-PSR connection between theFAP 1805 and the GANC in some embodiments. As shown, the SGSN 1815indicates (in Step 1) to the INC 1810 to release the PS resources (bothcontrol and user plane resources) allocated to the FAP, via the IuRelease Command message.

The INC 1810 confirms (in Step 2) resource release to SGSN 1815 by usingthe Iu Release Complete message. The INC 1810 commands (in Step 3) theFAP 1805 to release resources for the specific UE connection, using theGA-PSR RELEASE message. The FAP 1805 confirms (in Step 4) resourcerelease to the GANC using the GA-PSR RELEASE COMPLETE message and theGA-PSR state in the FAP 1805 changes to GA-PSR-IDLE.

V. MOBILITY MANAGEMENT

A. UE Addressing

The IMSI associated with the SIM or USIM in the UE is provided by theFAP to the INC when it registers a specific UE attempting to camp on theFAP. The INC maintains a record for each registered UE. For example,IMSI is used by the INC to find the appropriate UE record when the INCreceives a RANAP PAGING message.

B. Femtocell Addressing

The IMSI associated with the SIM or USIM in the FAP is provided by theFAP to the INC when it registers. The INC maintains a record for eachregistered FAP.

The Public IP address of the FAP is the address used by the FAP when itestablishes an IPSec tunnel to the GANC Security Gateway. Thisidentifier is provided by the GANC Security Gateway to the AAA server.In some embodiments, this identifier is used by the GANC network systemsto support location services (including E911) and fraud detection. Insome embodiments, this identifier is used by service providers tosupport QoS for IP flows in managed IP networks.

The Private IP address of the FAP (also referred to as the “remote IPaddress”) is used by the FAP “inside the IPSec tunnel.” This identifieris provided by the INC to the AAA server via the S1 interface when theFAP registers for Femtocell service. This identifier may be used by theFemtocell network systems in the future to support location services(including E911) and fraud detection.

In some embodiments, the Access Point ID (AP-ID) is the MAC address ofthe Femtocell access point through which the UE is accessing Femtocellservices. This identifier is provided by the FAP to the INC via the Upinterface, and by the INC to the AAA server via the S1 interface, whenthe FAP registers for Femtocell service. The AP-ID may be used by theFemtocell network systems to support location services (including E911,as described in “Location Based Routing” Section, below), and may alsobe used by the service provider to restrict Femtocell service access viaonly authorized FAPs (as described in “Femtocell Service Access Control”Section, below).

C. Femtocell Identification

The following points describe the Femtocell Identification strategy.

1. Location Area, Routing Area, Service Area Identification

In order to facilitate the Mobility Management functions in UMTS, thecoverage area is split into logical registration areas called LocationAreas (for CS domain) and Routing Areas (for PS domain). UEs arerequired to register with the network each time the serving locationarea (or routing area) changes. One or more location areas identifiers(LAIs) may be associated with each MSC/VLR in a carrier's network.Likewise, one or more routing area identifiers (RAIs) may be controlledby a single SGSN.

The LA and the RA are used in particular when the UE is in idle mode andthe UE does not have any active RRC connection. The CN would utilize thelast known LA (for CS domain) and RA (for PS domain) for paging of themobile when active radio connection is not available.

The Service Area Identifier (SAI) identifies an area consisting of oneor more cells belonging to the same Location Area. The SAI is a subsetof location area and can be used for indicating the location of a UE tothe CN. SAI can also be used for emergency call routing and billingpurposes.

The Service Area Code (SAC) which in some embodiments is 16 bits,together with the PLMN-Id and the Location Area Code (LAC) constitutethe Service Area Identifier.

SAI=PLMN-Id∥LAC∥SAC

In some embodiments, it is necessary to assign a distinct LAI to eachFAP in order to detect UE's mobility from the macro network to a FAP orfrom one FAP to another FAP. When a UE moves from the macro network to aFAP, the UE can camp on a FAP via its internal cell selection logic.However, if the UE is in idle mode, there will be no messages exchangedbetween the UE and the FAP, thus making it difficult for the FAP todetect the presence of the UE. In order to trigger an initial messagefrom UE, upon its camping on a specific FAP, the FAP will need to beassigned distinct location areas than the neighboring macro cells. Thiswill result in the UE's MM layer triggering a Location Update message tothe CN via the camped cell i.e. FAP.

UE's mobility from one FAP to another FAP must also be detected. TheUE's cell selection could select a neighboring FAP and it will camp onthe neighboring FAP without any explicit messaging. The neighboringFAP's Service Access Control (SAC) may not allow the camping of thatspecific UE, but without an initial explicit messaging there wouldn't bea way for the neighboring FAP to detect and subsequently to reject theUE.

Assuming the MCC and MNC components of the LAI remain fixed for eachoperator, LAI distinctiveness would be ensured by allocating a distinctLAC to each FAP, such that the LAC assigned to the FAP is different fromthe neighboring macro network cells and other neighboring FAPs.

However, the LAC space is limited to maximum of 64K (due to thelimitation of a 16 bit LAC attribute as specified in “Numbering,addressing and identification”), 3GPP TS 23.003, hereinafter “TS23.003”. As a result, the LAC allocation scheme must provide a mechanismto re-use the LACs for a scalable solution, and at the same timeminimize the operational impact on existing CN elements (MSC/SGSN).

In some embodiments, the following solution is utilized to meet theabove requirements. The LAC allocation is split into two separatecategories: (1) A pool of LACs managed by the FAP/AMS, and (2) A smallset of LACs (one per “Iu” interface) managed by the INC.

The first set of LACs is used by the FAP/AMS to assign a unique LAC toeach FAP such that it meets the following requirements (at the minimum):(1) Uniqueness with regards to the neighboring macro cells as well asother FAPs (this will ensure an initial message from the UE uponFemtocell selection and rove-in), and (2) Resolve conflicts with sharedLACs where multiple FAPs sharing the same LAC are not neighbors but areaccessed by the same UE (this is to allow the use of “LA not allowed”rejection code for UE rejection).

The second set of LACs (a much smaller set) is managed within each INCas follows, with the following key requirements: (1) Minimize the impacton the existing CN elements (such as minimal configuration andoperational impact), (2) Seamlessly integrate the existing functionalityfor routing of emergency calls to appropriate PSAPs, and (3) Seamlesslyintegrate existing functionality for the generation of appropriate calldetail records (CDRs) for billing purposes.

To meet the above requirements for the second set of LACs, each INCrepresents a “SuperLA” for a given Iu interface (i.e. MSC+SGSNinterface). This implies the MSC/SGSN can be configured with singleSuper LAI/Super RAI information for that INC. Note: this does not limitthe operator from configuring multiple Super LAI/Super RAI if necessary(e.g., to further subdivide the region served by a single INC intomultiple geographic areas).

In addition, the INC shall utilize the following mapping functionalityfor assignment of SuperLA: (1) When macro coverage is reported by theFAP, INC shall support mapping of the reported macro coverage to a SuperLAC, Super RAC and Service Area Code (SAC). The number of SACs utilizedwill be dependent on the granularity which the operator chooses forregional distribution (e.g. for emergency call routing, billing, etc),and (2) When no macro coverage is reported by the FAP, the INC shallhave the following logic for the Super LAC/RAC/SAC assignment: (a) Querythe AAA via the S1 interface for information on the “provisioned macrocoverage” for the given FAP IMSI. If S1 reports macro coverage (based oninformation stored in the subscriber DB), INC uses S1 macro informationto map Super LAC/RAC/SAC as above, and (b) If there is no informationabout the macro coverage from the S1 query, INC maps the FAP to defaultSuper LAC/RAC/SAC; (this could result in the INC routing traffic to CNin sub-optimal mechanism). To prevent this sub-optimal routing of UEtraffic to default MSC/SGSN, the following additional enhancement on theFAP may be utilized: (i) Upon a UE rove-in to this “no coverage” FAP,the FAP can gather information from the UE's initial location update(LU) request (since the UE will report last camped LAI), (ii) The FAPcan collect information from multiple UEs and construct a “derived”macro coverage information (the number of UEs utilized to derive macrocoverage could be algorithmic), (iii) Using this derived macro coverageinformation, the FAP shall send a GA-RC Register Update Uplink messageto the INC, and (iv) The INC shall utilize the macro coverageinformation reported via the GA-RC Register Update Uplink message to mapthe FAP to an appropriate Super LAC/RAC/SAC as above.

A distinct LAI for each FAP also implies a distinct RAI since the RAI iscomposed of the LAI and Routing Area Code (RAC). The LAI and RAI aresent to the FAP via the “System Information” attribute upon successfulregistration of FAP. The SAI, on the other hand, is relayed to the CN inthe “Initial UE message” (used to transfer initial L3 message from UE tothe CN).

The FAP is expected to provide Super LAC/RAC replacement in the NASmessages from the network to the UE (e.g. LU Accept or RAU accept). TheFAP must replace the “Super LAC/RAC” included in the relevant NASmessages from the network, with the appropriate locally assigned LAC/RACinformation in messages sent to the UEs camped on the FAP.

2. 3G Cell Identification

A 3G Cell Id identifies a cell unambiguously within a PLMN. A 3G cellidentifier is composed as below.

3G Cell Id=RNC-Id (12 bits)+cell Id (16 bits)

In some embodiments, the RNC-Id is 12 bits and cell Id is 16 bits,making the 3G Cell ID a 28 bits value. The 3G Cell Id in UMTS aremanaged within the UTRAN and are not exposed to the CN. As a result, thecell assignment logic can be localized to the UTRAN as long as it canensure uniqueness within a given PLMN.

The 3G Cell Id assigned to each FAP must be distinct from itsneighboring Femtocell primarily to avoid advertisement of the same cellId in system information broadcast by two adjacent FAPs, considering thefact the physical deployment of the FAPs are ad-hoc and not controlledby the operator. In some embodiments, each INC will be staticallyprovisioned with a unique RNC-Id and the RNC-id will be conveyed to theFAP via the System Information during registration. The FAP will beresponsible for the assignment of the 16 bit cell Id locally andconstruct the 3G cell using the combination of INC supplied RNC-Id andlocally assigned cell Id.

D. Femtocell Operating Configurations

Two Femtocell operating configurations are possible: common coreconfiguration and separate core configuration. In common coreconfiguration, the Femtocell LAI and the umbrella UTRAN's (e.g., theUTRAN that servers the subscriber's neighborhood) LAI are different, andthe network is engineered such that the same core network entities(i.e., MSC and SGSN) serve both the Femtocells and the umbrella UMTScells.

The primary advantage of this configuration is that subscriber movementbetween the Femtocell coverage area and the UMTS coverage area does notresult in inter-system (i.e., MAP) signaling (e.g., location updates andhandovers are intra-MSC). The primary disadvantage of this configurationis that it requires coordinated Femtocell and UMTS traffic engineering;e.g., for the purpose of MSC & SGSN capacity planning.

In separate core configuration, the Femtocell LAI and umbrella UTRAN'sLAI are different, and the network is engineered such that differentcore network entities serve the Femtocells and the umbrella UMTS cells.

The advantage of this configuration is that engineering of the Femtocelland UMTS networks can be more independent than in the Common CoreConfiguration. The disadvantage of this configuration is that subscribermovement between the Femtocell coverage area and the UMTS coverage arearesults in inter-system (i.e., MAP) signaling.

E. Femtocell Registration

The Femtocell registration process does not involve any signaling to thePLMN infrastructure and is wholly included within the Femtocell system(i.e., between the FAP, INC, and the AAA). There are two kinds ofFemtocell registrations: FAP registration and UE registration.

In FAP registration, upon power-up, the FAP registers with the INC. FAPregistration serves the following purposes: (1) It informs the INC thata FAP is now connected and is available at a particular IP address. Insome embodiments, the FAP creates a TCP connection to the INC beforeregistration. The TCP connection is identified by using one or more ofthe following information: source IP address, destination IP address,source TCP port, destination TCP port. The INC can extract the FAP IPaddress from the TCP connection, (2) It provides the FAP with theoperating parameters (such as LAI, Cell-Id, etc) associated with theFemtocell service at the current location. The “System Information”content that is applicable to the GAN Femtocell service is delivered tothe FAP during the registration process as part of GA-RC REGISTRATIONACCEPT message sent from the INC to the FAP. The FAP utilizes theinformation to transmit system parameters to the UE over the broadcastcontrol channel and (3) It allows the Femtocell system to provide theservice access control (SAC) and accounting functions (e.g., APrestriction and redirection). In some embodiments, the SAC andaccounting is done through the S1 interface.

In UE registration, upon Femtocell selection and cell camping, the UEinitiates a LU message towards the CN via the FAP. The FAP utilizes thismessage to detect presence of the UE on that specific FAP. The FAP theninitiates a registration message towards INC for the camped UE. UEregistration by the FAP serves the following purpose: (1) It informs theINC that a UE is now connected through a particular FAP and is availableat a particular IP address. The INC keeps track of this information forthe purposes of (for example) mobile-terminated calling, and (2) Itallows the INC to provide SAC functionality (e.g. using the S1interface, to validate if the specific UE should be allowed Femtocellservices from a specific FAP).

F. Mobility Management Scenarios

The following scenarios illustrate the message flows involved forvarious mobility management scenarios via the Femtocell system.

1. FAP Power On

In some embodiments, the FAP is initially provisioned with information(i.e. an IP address or a FQDN) about the Provisioning INC and thecorresponding Provisioning SeGW related to that INC. This informationcan be in the format of either a FQDN or an IP-address or anycombination of these. In case the FAP is not provisioned withinformation about the Provisioning SeGW, the FAP can derive a FQDN ofthe Provisioning SeGW from the IMSI (as described in TS 23.003). If theFAP does not have any information about either the Default INC or theServing INC and the associated SeGW stored, then the FAP completes theDiscovery procedure towards the Provisioning INC via the associatedSeGW. If the FAP has stored information about the Default/Serving INC onwhich it registered successfully the last time, the FAP skips thediscovery procedure and attempt registration with the Default/ServingINC as described below.

a) FAP Discovery Procedure

FIG. 19 illustrates the case in some embodiments when the FAP 1905powers on and does not have stored information on the Default/ServingINC, and then performs a discovery procedure with the provisioning GANC1910. The provisioning GANC 1910 includes a provisioning INC 1915, a DNS1920, and a SeGW 1925.

As shown, if the FAP 1905 has a provisioned or derived (as described inthe FAP power on sub-section, above) FQDN of the Provisioning SeGW, theFAP 1905 performs (in Step 1) a DNS query (via the generic IP accessnetwork interface) to resolve the FQDN to an IP address. If the FAP 1905has a provisioned IP address for the Provisioning SeGW 1925, the DNSsteps (Steps 1 and 2) are omitted. In some embodiments, the DNS Server1935 is a public DNS server accessible from the FAP. The DNS Server 1935returns (in Step 2) a response including the IP Address of theProvisioning SeGW 1925.

Next, the FAP 1905 establishes (in Step 3) a secure tunnel (e.g., anIPSec tunnel) to the Provisioning SeGW 1925. If the FAP 1905 has aprovisioned or derived FQDN of the Provisioning INC 1915, the FAP 1905performs (in Step 4) a DNS query (via the secure tunnel) to resolve theFQDN to an IP address. If the FAP has a provisioned IP address for theProvisioning INC 1915, the DNS steps (Steps 4 and 5) are omitted. TheDNS Server 1920 of the provisioning GANC 1910 returns (in Step 5) aresponse including the IP Address of the Provisioning INC 1915.

Next, the FAP 1905 sets up a TCP connection to a well-defined port onthe Provisioning INC. It then queries (in Step 6) the Provisioning INC1915 for the Default INC, using GA-RC DISCOVERY REQUEST. The messageincludes: (1) Cell Info: If the FAP detects macro network coverage thenthe FAP provides the detected UTRAN cell ID and the UTRAN LAI (for GSM,the FAP provides the GSM cell identification and the GSM LAI). If theFAP does not detect macro network coverage, the FAP provides the lastLAI where the FAP successfully registered, along with an indicator thatidentifies the last GERAN/UTRAN cell (e.g., by including a GERAN/UTRANcoverage Indicator Information Element (IE) which identifies the GERANor UTRAN cell coverage). The cell Info is the information of neighboringmacro cells which can be either GSM or UTRAN cells. There are multipleways for the FAP to obtain the neighboring cell information, e.g. usingpre-configuration on the FAP, obtaining the macro neighbor configurationvia AMS, or having the FAP radio scan the neighboring cells. If themacro coverage is GSM, then for the scan approach, the FAP must have thecapability and mechanism for scanning GSM cells, (2) FAP Identity: IMSI,and (3) The physical MAC address of the FAP: AP-ID. Optionally, if theINC 1915 has been configured for Service Access Control (SAC) over S1interface, the INC 1915 will via AAA server 1930 authorize the FAP 1905using the information provided in the GA-RC DISCOVERY REQUEST (Steps 6a-6 c).

The Provisioning INC 1915 returns (in Step 7) the GA-RC DISCOVERY ACCEPTmessage, using the information provided by the FAP (e.g. the cell ID),to provide the FQDN or IP address of the Default INC and its associatedDefault SeGW. This is done so the FAP 1905 is directed to a “local”Default INC in the HPLMN to optimize network performance. The DISCOVERYACCEPT message also indicates whether the INC and SeGW address providedshall or shall not be stored by the FAP 1905.

If the Provisioning INC 1915 cannot accept the GA-RC DISCOVERY REQUESTmessage, it returns (in Step 8) a GA-RC DISCOVERY REJECT messageindicating the reject cause. The secure IPSec tunnel to the ProvisioningSeGW is released (Step 9).

It is also be possible to reuse the same IPSec tunnel for FAPRegistration procedures. This is the case where a discovery procedureresults in the FAP to successfully find a “default” INC and a “default”SeGW. If the default SeGW is same as that used for discovery (i.e. theprovisioning SeGW), then the same IPSEC tunnel can be reused. In thiscase the IPSec tunnel is not released.

b) FAP Registration Procedure

Following the Discovery procedure the FAP establishes a secure tunnelwith the Security Gateway of the Default GANC, provided by theProvisioning GANC in the Discovery procedure, and attempts to registerwith the Default GANC. FIG. 20 illustrates FAP power on registrationprocedure of some embodiments. The Default GANC may become the ServingGANC for that connection by accepting the registration, or the DefaultGANC may redirect the FAP to a different Serving GANC. GANC redirectionmay be based on information provided by the FAP during the Registrationprocedure, operator chosen policy or network load balancing.

As shown in FIG. 20, if the FAP 2005 was only provided the FQDN of theDefault or Serving SeGW 2015, the FAP 2005 performs (in Step 1) a DNSquery (via the generic IP access network interface) to resolve the FQDNto an IP address. If the FAP 2005 has a provisioned IP address for theSeGW, the DNS steps (Steps 1 and 2) are omitted. The DNS Server 2010returns (in Step 2) a response including the IP address of theDefault/Serving SeGW 2015.

Next, the FAP 2005 sets up (in Step 3) a secure IPSec tunnel to the SeGW2015. This step may be omitted if an IPSec tunnel is being reused froman earlier Discovery or Registration. If the FAP 2005 was provided theFQDN of the Default or Serving INC, the FAP then perform (in Step 4) aDNS query (via the secure tunnel) to resolve the FQDN to an IP address.If the FAP 2005 has an IP address for the INC, the DNS steps (Steps 4and 5) are omitted. The DNS Server 2020 returns (in Step 5) a responseincluding the IP address of the Default/Serving INC 2025.

The FAP then sets up a TCP connection to the INC 2025. The TCP port caneither be a well-known or one that has been earlier received from thenetwork during Discovery or Registration. The FAP attempts to register(in Step 6) on the INC 2025 by transmitting the GA-RC REGISTER REQUEST.In some embodiment, the message includes one or more of the followinginformation: Registration Type, Cell Info, Neighboring FAP Info, thephysical MAC address of the FAP, FAP Identity, and location information.

The Registration Type indicates that the registering device is aFemtocell AP. This is indicated using the “GAN Classmark” IE (IEs aredefined further below). The Cell Info is the neighboring UTRAN/GERANcell ID retrieved as a result of system scan for neighbor information.The FAP must determine (using either scan results or pre-configuration),a single suitable macro cell information to be sent in the registration.

Neighboring FAP Info is information about neighboring FAPs operating inthe same PLMN and carrier frequency. This will help provide the INC withinformation such as the LAI and cell-ids in use by neighboring FAPs. Insome embodiments, the neighboring FAP information will not be provided.The physical MAC address of the FAP is the AP-ID (in some embodiments,AP-ID is the MAC address of the FAP associated Ethernet port). The FAPIdentity is the IMSI of the FAP. If GPS services are provided, locationinformation is also supported.

Optionally, if the INC 2025 has been configured for Service AccessControl (SAC) over S1 interface, the GANC will via AAA server 2030authorize the FAP using the information provided in the REGISTER REQUEST(Steps 6 a-6 c). If the INC 2025 accepts the registration attempt itresponds (in Step 7) with a GA-RC REGISTER ACCEPT. The message includes:(1) GAN Femtocell specific system information (e.g.) (i) Location-areaidentification comprising the mobile country code, mobile network code,and location area code corresponding to the Femtocell, and (ii) 3G Cellidentity identifying the cell within the location area corresponding tothe Femtocell. The message also includes GAN Femtocell CapabilityInformation indicated via the use of “GAN Control Channel” IE. In someembodiments, the GAN Femtocell Capability Information includeindications as to whether early Classmark sending is allowed, the GANmode of operation, whether GPRS is available, and whether the GANsupports dual transfer mode.

In the case the INC 2025 accepts the registration attempt, the TCPconnection and the secure IPSec tunnel are not released and aremaintained as long as the FAP is registered to this GANC. INC does notprovide operation parameters for radio management (such as carrierfrequency, scrambling code, etc) to the FAP. It is expected that the FAPwould obtain this information via the AMS or other pre-provisioningmechanisms.

Alternatively, the INC 2025 may reject the request. In this case, itresponds (in Step 8) with a GA-RC REGISTER REJECT indicating the rejectcause. The TCP connection and the secure IPSec tunnel are released andthe FAP 2005 shall act as defined in the “abnormal cases” Section,below. Alternatively, if the GANC has to redirect the FAP 2005 to(another) Serving GANC, it responds (in Step 9) with a GA-RC REGISTERREDIRECT providing the FQDN or IP address of the target Serving INC andthe associated SeGW. In this case the TCP connection is released (inStep 10) and the secure IPSec tunnel is optionally released depending onif the network indicates that the same IPSec tunnel can be reused forthe next registration. The GA-RC REGISTER REDIRECT message includeseither a single Serving SeGW and GANC address or a list of PLMNidentities and associated Serving SeGW and GANC addresses and anindication of whether GANC address(es) can be stored in the FAP forfuture use.

c) Abnormal Cases

If the Serving INC rejects the Register Request and does not provideredirection to another Serving INC, the FAP shall re-attemptRegistration to the Default INC including a cause indicating the failedregistration attempt and the Serving INC and SeGW with which theRegister Request failed. The FAP should also delete all storedinformation about this Serving GANC.

If the Default INC rejects a Registration Request and is unable toprovide redirection to suitable Serving INC, the FAP may re-attempt theDiscovery procedure to the Provisioning INC (including a causeindicating the failed registration attempt and the Default INC providedin the last Discovery procedure). The FAP should also delete all storedinformation about the Default GANC. The possible register reject causesfor FAP registration attempts are Network Congestion, Location NotAllowed, Geo-Location not know, IMSI not allowed, AP not allowed, andUnspecified.

2. FAP Initiated FAP Synchronization after TCP ConnectionReestablishment

In some embodiments, when FAP receives TCP Reset (TCP RST) after TCPconnection failure, the FAP tries to re-establish the signalingconnection using GA-RC Synchronization procedure. FIG. 21 illustratesthe messages associated with the FAP initiated synchronization procedurein some embodiments.

a) Initiation of the FAP Synchronization Procedure by the FAP

In some embodiments, when FAP receives TCP RESET after TCP connectionfailure, the FAP attempts to re-establish TCP connection once. Aftersuccessfully re-establishing TCP connection, the FAP 2105 sends (in Step1) GA-RC SYNCHRONIZATION INFORMATION to the GANC 2110 to synchronize thestate information. When the FAP is unsuccessful in re-establishing theTCP connection, the FAP releases the related local GA-CSR or GA-PSRresources, and continues as per sub-section “Handling of Lower Layerfaults” described further below.

b) Processing of the FAP Synchronization Information Message by the GANC

Upon receiving the GA-RC SYNCHRONIZATION INFORMATION message from theFAP, the GANC updates the FAP state information as specified in therequest. The GANC also verifies that the binding (IMSI, inner IPaddress) as received in the GA-RC SYNCHRONIZATION INFORMATION is thesame as the one that the FAP used as identity for authentication to theGANC-SeGW.

3. System Selection

In some embodiments, in the combined 3G network, both standard UMTS RNSand UMA Femtocell network coexists within the same or different PLMN.Standard UMTS UEs utilize both access options whichever is more optimalin a specific scenario. In these embodiment, no changes are required tothe PLMN selection procedures in the NAS layers (MM and above) in the UEas described in “Non-Access-Stratum functions related to Mobile Station(MS) in idle mode”, 3GPP TS 23.122. Also, in these embodiments, nochanges are required to the standard cell selection mechanism asdescribed in “User Equipment (UE) procedures in idle mode and proceduresfor cell reselection in connected mode”, 3GPP TS 25.304. The necessaryconfiguration and the system behavior for rove-in to Femtocell coverageand rove-out to the macro network coverage are described in thefollowing paragraphs.

During the service activation or provisioning update, the UMA FemtocellNetwork provides the FAP with radio parameters such as the operatingUARFCN and a list of primary scrambling codes for the Femtocell. Theprovisioning parameters will also include the list of UARFCNs/scramblingcodes associated with the neighboring macro cells.

The FAP then performs a neighborhood scan for the existence of macrocoverage using the macro UARFCN information. If multiple macro networkcells are detected in the FAP scan, the FAP selects the best suitablemacro cell for the purpose of reporting it to the Serving INC during FAPregistration. The FAP also stores the macro cell list to be provided asa neighbor list for the camping UEs.

The FAP also scans the neighborhood for the existence of other FAPswithin the same PLMN. It then selects unused {UARFCN, SC} pair from theprovisioned list of available pairs such that the selected {UARFCN, SC}does not conflict with any neighboring FAP's {UARFCN, SC} combination.

The FAP attempts to register with the Serving INC (obtained viaDiscovery/Registration mechanisms as described in the FAP discoveryprocedure and FAP registration procedure Sections above) and includesinformation about the selected macro cell and a list of neighboringFAPs. The Serving INC uses information provided during registration toassign network operating parameters for the registering FAP such as theLAI, 3G cell-id, service area, etc.

The Serving INC returns the network operating parameters to theregistering FAP using the register accept message. The FAP uses acombination of information obtained through the initial provisioning andRegistration and broadcasts appropriate System Information to UEs to beable to select Femtocell service and camp on the FAP.

The macro network RNCs are provisioned with the list of {UARFCN, SC}associated with Femtocell neighbors. Since the Femtocell network has tobe able to scale to millions of FAPs and the deployment location cannotbe controlled, the macro network RNCs are provisioned with a list of5-10 {UARFCN, SC} combinations corresponding to the neighboring FAPs. Asa result of the limitations associated with neighbor list provisioningon the macro RNC, the FAP will need to select one of the 5-10provisioned {UARFC, SC} pairs for its operation such that no twoneighboring FAPs (determined via FAPs' scan) shall re-use the same pairfor its operation.

The macro RNC shall provide the FAP neighbor list information to the UEscamped on the macro network and using the specific RNC. This will resultin the UEs making periodic measurements on the FAP neighbor list.

As the UE comes within the coverage area of the FAP and its signal levelbecomes stronger, the UE will select the Femtocell. The UEcell-reselection i.e. rove-in to FAP cell can be enhanced via twopossible mechanisms: (1) The FAP cell can be in a different HPLMN(equivalent PLMN list) and will be selected via preferred equivalentPLMN selection. This assumes that the UE's current camped macro cell isnot in the equivalent PLMN list, and (2) The FAP will broadcast systeminformation (such as Qqualmin and Qrxlevmin) so that UE shall prefer theFAP cell in the presence of other macro cell coverage.

Upon cell reselection and camping on the FAP cell, the UE will initiatea location registration since the FAP LAI is different than the LAI ofthe previously camped macro cell.

4. UE Registration

The UE, upon camping on the FAP (via its internal cell selectionmechanism), will initiate a NAS layer Location Update procedure towardsthe CN via the FAP (The LU is triggered since the FAP broadcasts adistinct LAI than its neighboring macro cells and other neighboringFemtocells). The FAP will intercept the Location Update message andattempt to register the UE with the INC as illustrated in FIG. 22. Aperson of ordinary skill in the art would appreciate that a UE alwaysinitiates location update procedure towards the core network, i.e., theUE uses the upper protocol layers that are directly exchanged with thecore network. As described in this sub-section and several othersub-sections below, the disclosed FAP has the capability to interceptthis message and to attempt to register the UE with the INC.

As shown, the UE 2205 establishes (in Step 1 a) a radio resource control(RRC) connection with the FAP 2210 on which it camps. The UE 2205 starts(in Step 1 b) a Location Update procedure towards the CN. In someembodiments, for networks supporting network mode 1, where there is a Gsinterface between the MSC and SGSG, the UE triggers a combined RoutingArea (RA)/Location Area (LA) update instead of the initial LA updateupon rove-in to FAP. The FAP 2210 will intercept the Location Updaterequest (or the combined RA/LA update request) and attempts to registerthe UE with the associated Serving INC over the existing IPSec tunnel.Optionally, the FAP may request (in Step 1 c) the IMSI of the UE if theLocation Update is done (in Step 1 d) using the TMSI, since the initialregistration for the UE must be done using the permanent identity i.e.the IMSI of the UE.

Next, the FAP 2210 sets up (in Step 2) a separate TCP connection (foreach UE) to a destination TCP port on the INC 2215. The INC destinationTCP port is the same as that used for FAP registration. The FAP 2210attempts to register the UE 2205 on the INC 2215 using the UE specificTCP connection by transmitting (in Step 3) the GA-RC REGISTER REQUEST.The message includes Registration Type (which indicates that theregistering device is a UE. This is indicated using the “GAN Classmark”IE), Generic IP access network attachment point information (i.e.,AP-ID), UE Identity (i.e., UE-IMSI), and FAP identity (i.e., FAP-IMSI).In some embodiments, the AP-ID is the MAC address of the FAP.

Optionally, if the INC 2215 has been configured for Service AccessControl (SAC) over S1 interface, the INC 2215 will, via AAA server 2220,authorize the UE using the information provided in the REGISTER REQUEST(Steps 3 a-3 c). The authorization logic on the AAA server 2220 wouldalso check to see if the UE 2205 is allowed Femtocell access using thespecific FAP.

If the INC 2215 accepts the registration attempt it responds (in Step 4)with a GA-RC REGISTER ACCEPT. Next, the FAP 2210 establishes (in Step 5)a GA-CSR connection with the INC 2215. The FAP 2210 encapsulates (inStep 6) the Location Update NAS PDU within a GA-CSR UL DIRECT TRANSFERmessage that is forwarded to the INC 2215 via the existing TCPconnection.

Next, the INC 2215 establishes a SCCP connection to the CN 2225 andforwards (in Step 7) the Location Update request (or the combined RA/LAupdate request) NAS PDU to the CN 2225 using the RANAP Initial UEMessage. Subsequent NAS messages between the UE 2205 and core network2225 will be sent between INC 2215 and CN 2225 using the RANAP DirectTransfer message.

Next, the CN 2225 authenticates (in Step 8) the UE 2205 using standardUTRAN authentication procedures. The CN 2225 also initiates the SecurityMode Control procedure described in the Security Mode Control Subsectionunder Femtocell Security Section further below. The CN 2225 indicates(in Step 9) it has received the location update and it will accept thelocation update using the Location Update Accept message to the INC2215.

The INC 2215 forwards (in Step 10) this message to the FAP 2210 in theGA-CSR DL DIRECT TRANSFER. The FAP 2210 will relay (in Step 11) theLocation Update Accept over the air interface to the UE 2205. Once theUE 2205 has been successfully registered (by the FAP) with the INC 2215and performed a successful location update, the FAP 2210 will expect aperiodic LU for that UE (the enabling and the periodicity of the LU iscontrolled by the FAP via System Information broadcast from the FAP tothe UE). This exchange will serve as a keep-alive between the FAP 2210and the UE 2205 and will help the FAP 2210 detect idle UE's moving awayfrom the camped FAP 2210 without explicit disconnect from the network.

a) Abnormal Cases

If the Serving INC rejects the UE specific Register Request, the FAPshall reject the corresponding “Location update” request from the UEusing appropriate reject mechanisms (example: RRC redirection to anothercell or reject the LU with reject cause of “Location Area not allowed”,etc). The FAP shall tear down the corresponding TCP session for thespecific UE. The possible register reject causes for UE specificregistration attempts are (1) AP not allowed (implies UE not allowed onFAP for the UE specific registration), (2) IMSI not allowed, (3)Location not allowed, (4) Unspecified, and (5) FAP not registered.

5. UE Rove Out

FIG. 23 scenario illustrates the case when the UE leaves the Femtocellcoverage area while idle. As shown, upon successful GAN registration andlocation update (LU) of the UE 2305, the FAP 2310 will monitor (in Step1) the UE 2305 via periodic location updates. The enabling and theperiodicity of the LU is controlled by the FAP 2310 via SystemInformation broadcast from the FAP to the UE. This exchange will serveas a keep-alive between the FAP and the UE.

Next, FAP 2310 determines (in Step 2) that the UE 2305 is no longercamped on the FAP (roved out), as a result of missing a number ofperiodic location updates from the UE. Once, the FAP determines that theUE has roved out, the FAP informs the GANC that the UE has detached bysending (in Step 3) a GA-RC DEREGISTER message to the INC 2315 using theassociated TCP connection. Since a TCP connection from the FAP to theGANC is unique for each UE, sending GA-RC DEREGISTER message on thespecific TCP connection implies deregistration of the specific UE. Next,the GANC removes (in Step 4) any associated UE context upon receivingthe deregister message on the UE specific TCP connection. In someembodiments, the context associated with a UE includes states and otherinformation that the GANC keeps for each UE which is successfullyregistered. The FAP 2310 also releases (in Step 4) the UE specific TCPconnection to the INC.

6. UE Power Down with IMSI Detach

FIG. 24 illustrates the case when the UE powers down and performs anIMSI detach via the GAN network in some embodiments. As shown, UE 2405in idle mode initiates (in Step 1) power off sequence. Next, the UE 2405establishes (in Step 2) an RRC Connection with the FAP 2410. The UE send(in Step 3) a MM Layer IMSI-Detach message over the air interface to theFAP. The FAP 2410 establishes (in Step 4) a GA-CSR connection with theINC 2415.

The FAP 2410 encapsulates the IMSI-Detach NAS PDU within a GA-CSR ULDIRECT TRANSFER message that is forwarded (in Step 5) to the INC 2415via the existing TCP connection. The INC 2415 establishes a SCCPconnection to the CN 2420 and forwards (in Step 6) the IMSI-Detach NASPDU to the CN 2420 using the RANAP Initial UE Message. The CN 2420initiates (in Step 7) a normal resource cleanup via RANAP Iu ReleaseCommand to the INC 2415. The Iu Release from the CN 2420 results in INC2415 tearing down (in Step 8) the corresponding GA-CSR connection.

Next, INC 2415 acknowledges (in Step 9) resource cleanup via RANAP IuRelease Complete message to the CN. FAP 2410 deregisters (in Step 10)the UE using the UE specific TCP connection. In some embodiments, theFAP utilizes the mechanism described in Subsection “UE rove out” aboveto detect that the UE has roved and trigger the UE deregistration. As anoptimization, the FAP can also monitors the IMSI-Detach NAS message fromthe UE and trigger deregistration of the UE.

Next, the FAP 2410 releases (in Step 11) the UE specific TCP connection.FAP initiates (in Step 12) RRC Connection release procedure towards theUE. Finally, the UE powers off (in Step 13).

7. UE Power Down without IMSI Detach

The sequence of events is same as UE Roving out of Femtocell asdescribed in Subsection “UE rove out” above.

8. Loss of Up Interface Connectivity

FIG. 25 illustrates the case when Up interface connectivity is lost. Asshown, the UE 2505 is in idle mode. The FAP 2510 periodically sends (inStep 1) GA-RC KEEP ALIVE message to the INC 2515 to check that the TCPconnection exists. In Step 2, the TCP (or IP) connectivity between theFAP 2510 and INC 2515 is lost (e.g., due to a broadband networkproblem).

If the INC detects (in Step 3) the loss of connectivity, it releases theresources assigned to the FAP (e.g., TCP connection) and deletes thesubscriber record (i.e., performs a local deregistration of the FAP).Optionally, the INC implementation may also delete UE specificconnections originating on that FAP.

If the FAP 2510 detects (in Step 4) the loss of TCP connectivity and ifthe loss is on the FAP specific TCP connection, the FAP 2510 attempts(in Step 5) to re-establish the TCP connection and re-register with theINC. If the FAP re-establishes connectivity and re-registers before theINC detects the problem, the INC must recognize that the FAP is alreadyregistered and adjust accordingly (e.g., release the old TCP connectionresources). In some embodiment, the FAP specific TCP is a unique TCPconnection dedicated to the FAP and is used for FAP IMSI relatedsignaling to the INC such as FAP registration, FAP call setup if the FAPoffers local calling using the FAP IMSI, etc.

Different embodiments use different methods for the FAP to detect theloss of a TCP connection. In some embodiments, the TCP sub-layer (TCPstack) in the FAP indicates (to the upper layers) if the connectivity tothe other end point (i.e., the INC) is lost. The notification from theTCP sub-layer on the FAP can happen either when the upper layers attemptto transmit data over the TCP connection or the stack can detectconnectivity loss via a TCP Keep Alive mechanism.

When the FAP is unsuccessful in re-establishing connectivity, the FAPwill do the followings (not shown) to deregister all the UEs currentlycamped on the FAP: (1) The FAP sends a GA-RC DEREGISTER message to theINC using the currently established TCP connection for each UE, (2)releases the TCP connection towards the GANC, and (3) releases allresources associated with the deregistered UE.

Additionally, the FAP 2510 forces (in Step 6) all the UEs, currentlycamped on that FAP, to do a cell-reselection and rove out of Femtocellcoverage. If the TCP connectivity loss is detected on the UE specificconnection, the FAP will deregister the UE and trigger cell reselectionon the UE immediately without attempting to re-establish the UE specificTCP connection. Finally, the UE 2505, as a result of the cellre-selection, will switch (in Step 7) to UMTS macro cell 2520 (if UMTSmacro network coverage is available).

9. INC-Initiated Deregister

In some embodiments, the INC deregisters the FAP under the followingerror cases: (1) INC receives GA-RC REGISTER UPDATE UPLINK message, butFAP is not registered, (2) INC receives GA-RC REGISTER UPDATEUPLINKmessage, but encounters a resource error and cannot process the message,(3) INC receives GA-RC REGISTER UPDATE UPLINK message with new macronetwork cell information, and the macro cell is Femtocell-restricted,and (4) INC receives a GA-RC REGISTER UPDATE UPLINK message and sends arequest to the AAA server for a registered FAP, and one of the followinghappens: (a) INC receives an authentication failure for the user fromAAA server, (b) INC doesn't receive a response from AAA server, andtransaction timer expires, or (c) S1 interface is enabled but no AAAserver is configured, so the user couldn't be authenticated. In someembodiments, the INC deregisters the UE when the INC receives GA-RCSYNCHRONIZATION INFORMATION message for a UE that is not registered.

10. FAP-Initiated Register Update

FIG. 26 illustrates a scenario where the FAP initiates a registrationupdate in some embodiments. As shown, a register update is triggered (inStep 1) in the FAP 2605 (e.g., Detection of macro network coverage). TheFAP sends (in Step 2) a GA-RC REGISTER-UPDATE-UPLINK to the INC 2610.

The INC 2610 exchanges (in Steps 3 a-3 c) S1 RADIUS messages with theAAA server 2615 for service access control (SAC). Based on the outcomeof SAC, additional procedures may be triggered (in Step 4) by thisoperation (e.g., deregistration or register update downlink).

11. INC-Initiated Register Update

FIG. 27 illustrates a scenario where the INC initiates a registrationupdate. As shown, a register update is triggered (in Step 1) in the INC2715 (e.g. due to change in SAC list for the FAP, or change in SystemInformation, etc).

Next, the INC 2715 sends (in Step 2) a GA-RC REGISTER UPDATE DOWNLINKmessage to the FAP 2710. As shown, some other procedures may betriggered (in Step 3) by this operation (e.g. FAP 2710 rejecting UEs2705 due to updated SAC list received from the INC).

12. FAP Initiated UE Synchronization after TCP ConnectionReestablishment

In some embodiments, when FAP receives TCP RST after TCP connectionfailure, the FAP tries to re-establish the signaling connection usingGA-RC Synchronization procedure. FIG. 28 illustrates the FAP initiatedsynchronization procedure in some embodiments.

a) Initiation of the UE Synchronization Procedure by the FAP

In some embodiments, when FAP receives TCP RST after TCP connectionfailure, the FAP attempts to re-establish TCP connection once. As shownin FIG. 28, after successfully re-establishing TCP connection, the FAP2805 sends (in Step 1) GA-RC SYNCHRONIZATION INFORMATION to the GANC2810 to synchronize the UE's state information. When unsuccessful, theFAP releases the resources for the UE and forces the UE to rove-out ofthe FAP and select an alternate cell (either a macro cell or anotherFAP) for camping

b) Processing of the UE Synchronization Information Message by the GANC

Upon receiving the GA-RC SYNCHRONIZATION INFORMATION message from theFAP on a UE's TCP connection, the GANC updates the UE state informationas specified in the request. The GANC also verifies that the associatedFAP is in the registered state. When the FAP is not in registered state,the GANC deregisters the UE by sending a GA-RC-DEREGISTER message (notshown) with reject cause code “FAP not registered” to the FAP on theUE's TCP connection. When the GA-RC layer in the GANC has submitted theGA-RC DEREGISTER message to the TCP layer, it initiates the release ofits half of the bidirectional TCP connection. The GANC also verifiesthat the binding (IMSI, TCP connection) as received in the GA-RCSYNCHRONIZATION INFORMATION is valid.

VI. CALL MANAGEMENT

A. Voice Bearer Establishment (Using Iu-UP Over AAL2)

FIG. 29 illustrates the normal procedures associated with successfullyestablishing the voice bearer between the UE and MSC for mobileoriginated (MO) or mobile terminated (MT) call purposes in someembodiments. As shown, the signaling for a call origination ortermination is in progress (in Step 1) between UE 2905, FAP 2910, GANCMGW 2915, INC 2920, and MSC 2925. The MSC 2925 sends (in Step 2) a RANAPAssignment Request (RAB) message to the INC 2920. The assignment requestincludes the address for ALCAP signaling (an ATM E.164 or NSAP address)and also the binding-id.

Next, the INC 2920 requests (in Step 3) the GANC MGW 2915 to prepare abearer connection between the endpoints (VoIP towards the FAP and Iu-UPover AAL2 towards the MSC). The MGW 2915 initiates (in Step 4) ALCAPsignaling towards the MSC 2925 using the ATM address and the binding-id.

Next, the MSC 2925 acknowledges (in Step 5) the AAL2 connection requestusing the ALCAP Establish confirm message. At this point (Step 6) anAAL2 connection with appropriate QoS exists between the GANC MGW and theMSC. The GANC MGW then sends (in Step 7) an Iu-UP control (Iu-INIT)message over this AAL2 connection to request Iu-UP initialization

The MSC 2925 responds (in Step 8) with Iu-UP init acknowledgement(Iu-INIT ACK). Next, the MGW 2915 assigns a MGW IP address and port forthe VoIP side of the connection. The MGW sends (in Step 9) the VoIPinformation to the INC using a Prepare Bearer Ack message. Next, the INC2920 sends (in Step 10) a GA-CSR ACTIVATE CHANNEL message to the FAP2910 and starts a timer (e.g., Tqueuing, as described in “UTRAN Iuinterface Radio Access Network Application Part (RANAP) signaling”, 3GPPTS 25.413) to ensure that the RANAP Assignment Response is sent to theMSC on or before the expiry of Tqueuing. The GA-CSR ACTIVATE CHANNELmessage includes the VoIP connection description created by the GANCMGW.

The FAP 2910 initiates (in Step 11) appropriate RRC layer Radio BearerSetup message towards the UE 2905. The UE confirms (in Step 12) thesetup via Radio Bearer Setup Complete message to the FAP. The FAP sends(in Step 13) a GA-CSR ACTIVATE-CHANNEL-ACKNOWLEDGE message to the INC,including the local IP address and port to be used for the VoIPconnection.

The INC requests (in Step 14 a) the GANC MGW, to modify the previouslycreated connection and send the voice stream to the IP address and portprovided by the FAP. The GANC MGW acknowledges (in Step 14 b) theconnection modification. The INC 2920 acknowledges (in Step 15)completion of the traffic channel establishment to the FAP 2910 via theGA-CSR ACTIVATE-CHANNEL COMPLETE message.

The INC 2920 signals (in Step 16) the MSC 2925 about the RAB assignmentcompletion. At this point (Steps 17 a-17 c), there is voice bearerbetween the UE 2905 and MSC 2925 via the FAP 2910 and the GANC MGW 2915.The rest of the call establishment continues after the voice bearerestablishment.

B. Call Management Scenarios

The following scenarios illustrate the message flows involved forvarious call management scenarios via the Femtocell.

1. Mobile Originated Call

FIG. 30 illustrates a mobile originated call in some embodiments. Thescenario shown is for a mobile-to-PSTN call. As shown, the UE 3005 inGAN idle mode originates (in Step 1) a call. The UE 3005 establishes (inStep 2) a RRC connection with the FAP 3010. Upon request from the upperlayers, the UE sends (in Step 3) the CM Service Request to the FAP.

The FAP performs (in Step 4) the GA-CSR Connection Establishmentprocedure with the INC as described in previous sections. The FAP 3010then forwards (in Step 5) the CM Service Request to the INC 3015 using aGA-CSR UL DIRECT TRANSFER message. Next, the INC 3015 establishes a SCCPconnection to the MSC 3020 and forwards (in Step 6) the CM ServiceRequest to the MSC using the RANAP Initial UE Message. Subsequent NASmessages between the UE and MSC will be sent between INC and MSC usingthe RANAP Direct Transfer message.

Next, the MSC 3020 authenticates (in Step 7) the UE 3005 using standardUTRAN authentication procedures. The MSC also initiates (in Step 7) theSecurity Mode Control procedure described in previous sections. The UEsends (in Step 8) the Setup message to the FAP providing details on thecall to the MSC and its bearer capability and supported codecs.

The FAP forwards (in Step 9) this message within the GA-CSR UL DIRECTTRANSFER between the FAP and the INC. The INC relays (in Step 10) theSetup message to the MSC using a RANAP Direct Transfer message.

The MSC 3020 indicates (in Step 11) it has received the call setup andit will accept no additional call-establishment information using theCall Proceeding message to the INC. The INC forwards (in Step 12) thismessage to the FAP in the GA-CSR DL DIRECT TRANSFER. The FAP then relays(in Step 13) the Call Proceeding message to the UE over the airinterface. At this point (Step 14) an end to end bearer path isestablished between the MSC and UE using one of the procedures shown inprevious section.

The MSC 3020 constructs (in Step 15) an ISUP IAM using the subscriberaddress, and sends it towards the called party's destination exchange3025. The destination Exchange responds (in Step 16) with an ISUP ACMmessage. The MSC then signals to the UE, with the Alerting message, thatthe called party is ringing. The message is transferred (in Step 17) tothe INC.

The INC forwards (in Step 18) the Alerting message to the FAP in theGA-CSR DL DIRECT TRANSFER. The FAP relays (in Step 19) the Alertingmessage to the UE and if the UE has not connected the audio path to theuser, it shall generate ring back to the calling party. Otherwise, thenetwork-generated ring back will be returned to the calling party.

The called party answers and the destination Exchange indicates this (inStep 20) with an ISUP ANM message. The MSC signals that the called partyhas answered, via the Connect message. The message is transferred (inStep 21) to the INC. The INC forwards (in Step 22) the Connect messageto the FAP in the GA-CSR DL DIRECT TRANSFER.

The FAP relays (in Step 23) the Connect message to the UE and the UEconnects the user to the audio path. If the UE is generating ring back,it stops and connects the user to the audio path. The UE sends (in Step24) the Connect Ack in response, and the two parties are connected forthe voice call. The FAP relays (in Step 25) this message within theGA-CSR UL DIRECT TRANSFER between the FAP and the INC.

The INC forwards (in Step 26) the Connect Ack message to the MSC. Theend-to-end two way path is now (Step 27) in place and bi-directionalvoice traffic flows between the UE and MSC through the FAP and the INC.A FAP with local service can support MO using the FAP IMSI. Thenecessary message flows would be similar as above without the FAP-UEmessage exchanges over the air interface.

2. Mobile Terminated Call

FIG. 31 illustrates a mobile terminated call. The scenario shown is fora PSTN-to-mobile call. As shown, the MSC (i.e., the GMSC function)receives (in Step 1) a call from party A intended for the Femtocellsubscriber 3105. The MSC 3120 sends (in Step 2) a RANAP Paging messageto the INC 3115 identified through the last Location Update received byit and includes the TMSI if available. The IMSI of the mobile beingpaged is always included in the request.

The INC 3115 identifies the UE registration context using the IMSIprovided by the MSC. It then pages (in Step 3) the associated FAP 3110using the GA-CSR PAGING REQUEST message. The message includes the TMSI,if available in the request from the MSC, else it includes only the IMSIof the mobile.

The FAP 3110 relays (in Step 4) the Paging request to the UE. The FAPmay use Paging Type 1 or 2 based on the RRC state of the UE as describedin “Radio Resource Control (RRC) protocol specification”, 3GPP TS25.331, hereinafter “TS 25.331”. The UE 3105 establishes (in Step 4 a) aRRC connection with the FAP 3110 if one doesn't exist. This step isomitted if there is an already existing RRC connection (e.g. an RRCconnection may have been established for PS domain).

Next, the UE 3105 processes the paging request and sends (in Step 5) thePaging response to the FAP 3110. The FAP then performs (in Step 5 a) theGA-CSR Connection Establishment procedure with the INC as described inprevious sections. The FAP responds (in Step 6) with a GA-CSR PAGINGRESPONSE.

The INC 3115 establishes an SCCP connection to the MSC 3120. The INC3115 then forwards (in Step 7) the paging response to the MSC using theRANAP Initial UE Message. Subsequent NAS messages between the UE andcore network will be sent using the RANAP Direct Transfer message. TheMSC then authenticates (in Step 8) the UE using standard UTRANauthentication procedures. The MSC also initiates (in Step 8) theSecurity Mode Control procedure described in previous sections.

The MSC initiates (in Step 9) call setup using the Setup message sent tothe FAP via INC. The INC then forwards (in Step 10) this message to theFAP in the GA-CSR DL DIRECT TRANSFER message. The FAP relays (Step 11)the Setup message to the UE

The UE 3105 responds (in Step 12) with Call Confirmed after checkingit's compatibility with the bearer service requested in the Setup andmodifying the bearer service as needed. If the Setup included the signalinformation element, the UE alerts the user using the indicated signal,else the UE alerts the user after the successful configuration of theuser plane

The FAP relays (in Step 13) the Call Confirmed to the INC using theGA-CSR UL DIRECT TRANSFER message. The INC then forwards (in Step 14)the Call Confirmed message to the MSC using RANAP direct transfermessage. At this point (Step 15) an end to end bearer path isestablished between the MSC 3120 and UE 3105 using the procedure forvoice bearer establishment as described in previous sections.

The UE signals (in Step 16) that it is alerting the user, via theAlerting message to the FAP. The FAP relays (in Step 17) the Alertingmessage to the INC using the GA-CSR UL DIRECT TRANSFER. The INC (in Step18) forwards the Alerting message to the MSC.

The MSC 3120 returns (in Step 19) a ISUP ACM message towards theoriginating PSTN Exchange 3125. The UE signals (in Step 20) that thecalled party has answered, via the Connect message. The FAP relays (inStep 21) the Connect message to the INC in the GA-CSR UL DIRECT TRANSFERmessage.

Next, the INC forwards (in Step 22) the Connect message to the MSC. TheMSC then returns (in Step 23) an ISUP ANM message towards theoriginating PSTN exchange 3125. The MSC acknowledges (in Step 24) viathe Connect Ack message to the INC. The INC forwards (in Step 25) thismessage to the FAP in the GA-CSR DL DIRECT TRANSFER.

The FAP relays (in Step 26) the Connect Ack to the UE. The two partieson the call are connected on the audio path. The end-to-end two way pathis now (Step 27) in place and bi-directional voice traffic flows betweenthe UE and MSC through the FAP and the INC. A FAP with local service cansupport MT using the FAP IMSI. The necessary message flows would besimilar as above without the FAP-UE message exchanges over the airinterface.

3. Call Release by Femtocell Subscriber

FIG. 32 illustrates a scenario where a Femtocell call is released by theFemtocell subscriber in some embodiments. As shown, the Femtocellsubscriber 3205 requests (in Step 1) call release (e.g., by pressing theEND button). Upon request from the upper layers, the UE sends (in Step2) the Disconnect message to the FAP 3210. The FAP forwards (in Step 3)the Disconnect message to the INC (embedded in a GA-CSR UL DIRECTTRANSFER message).

The INC 3220 relays (in Step 4) the Disconnect message to the MSC 3225via RANAP Direct Transfer message. The MSC 3225 sends (in Step 5) anISUP RELEASE message towards the other party 3230. The MSC sends (inStep 6) a Release to the INC using RANAP Direct Transfer message.

Next, the INC forwards (in Step 7) the Release message to FAP usingGA-CSR DL DIRECT TRANSFER message. The FAP then sends (in Step 8) theRelease message to the UE over the air interface. The UE 3205 confirms(in Step 9) the Release via the Release Complete message to the FAP. TheFAP relays (in Step 10) the Release Complete message to the INC usingGA-CSR UL DIRECT TRANSFER message

The INC forwards (in Step 11) the message to the MSC using RANAP DirectTransfer message. At this point, the MSC considers the connectionreleased. Sometime after Step 5, the MSC receives (in Step 12) an ISUPRLC message from the other party's exchange.

The MSC 3225 sends (in Step 13) an Iu Release command to the INC 3220indicating a request to release the call resources. The SCCP ConnectionIdentifier is used to determine the corresponding call. The INC 3220requests (in Step 14) the GANC MGW 3215 to release associated resourceswith the call. The GANC MGW 3215 confirms (in Step 15) release ofassociated resources.

The INC initiates (in Step 16) a GA-CSR Connection Release proceduretowards the FAP (as described in previous sections). The FAP in turnreleases (in Step 17) any radio resource associated for the specificcall. If there is an active PS session for the UE, the RRC connectionmay not be released by the FAP, and only the corresponding CS radiobearers are released. Finally, the INC acknowledges (in Step 18) theresource release to the MSC using the Iu Release Complete message to theMSC. The SCCP connection associated with the call between the INC andthe MSC is released as well

4. Other Calling Scenarios

The following services are supported by the Femtocell solution:

-   -   Calling Line Identification Presentation (CLIP)    -   Calling Line Identification Restriction (CLIR)    -   Connected Line Identification Presentation (CoLP)    -   Connected Line Identification Restriction (CoLR)    -   Call Forwarding Unconditional    -   Call Forwarding Busy    -   Call Forwarding No Reply    -   Call Forwarding Not Reachable    -   Call Waiting (CW)    -   Call Hold (CH)    -   Multi Party (MPTY)    -   Closed User Group (CUG)    -   Advice of Charge (AoC)    -   User User Signaling (UUS)    -   Call Barring (CB)    -   Explicit Call Transfer (ECT)    -   Name Identification    -   Completion of Calls to Busy Subscriber (CCBS)

These supplementary services involve procedures that operate end-to-endbetween the UE and the MSC. Beyond the basic Direct Transfer ApplicationPart (DTAP) messages already described for MO and MT calls, thefollowing DTAP messages are used for these additional supplementaryservice purposes:

-   -   HOLD    -   HOLD-ACKNOWLEDGE    -   HOLD-REJECT    -   RETRIEVE    -   RETRIEVE-ACKNOWLEDGE    -   RETRIEVE-REJECT    -   FACILITY    -   USER-INFORMATION    -   CONGESTION-CONTROL    -   CM-SERVICE-PROMPT    -   START-CC    -   CC-ESTABLISHMENT    -   CC-ESTABLISHMENT-CONFIRMED    -   RECALL

These DTAP message are relayed between the UE and MSC by the INC in thesame manner as in the other call control and mobility managementscenarios described in this disclosure. A generic example is illustratedin FIG. 33. As shown (in Step 1), there is an existing MM connectionestablished between the UE and the MSC for an ongoing call. The userrequests (in Step 2) a particular supplementary service operation (e.g.,to put the call on hold).

The UE 3305 sends (in Step 3 a) the HOLD message to the FAP 3310 overthe air. The FAP in turn forwards (in Step 3 b) the message to INC3315), embedded in a GA-CSR UPLINK DIRECT TRANSFER message. The INCrelays (in Step 3 c) the DTAP HOLD message to the MSC 3320 over theIu-interface.

Next, the DTAP HOLD-ACK message is sent (in Steps 4 a-4 c) from MSC 3320to UE 3305 through the INC and FAP. Later in the call, the user requests(in Step 5) another supplementary service operation (e.g., to initiate aMultiParty call).

The UE sends (in Step 6 a) the FACILITY message to the FAP over the air.The FAP in turn forwards (in Step 6 b) the message to the INC. The INCrelays (in Step 6 c) the DTAP FACILITY message to the MSC over theIu-interface. Finally, the DTAP FACILITY message including the responseis sent (in Steps 7 a-7 c) from MSC to UE through the INC and FAP.

VII. PACKET SERVICES

A. GA-PSR Transport Channel Management Procedures

The GA-PSR Transport Channel (GA-PSR TC) provides an association betweenthe FAP and INC for the transport of the user data over the Upinterface. Given that the Femtocell user data transport is UDP based,the GA-PSR Transport Channel is associated with corresponding FAP andINC IP addresses and UDP ports used for user data transfer. The FAP andINC manage the GA-PSR Transport Channel based on the requests for datatransfer and the configurable GA-PSR TC Timer.

1. States of the GA-PSR Sub-Layer

The GA-PSR Transport Channel (GA-PSR TC) management procedures are thebasic procedures for PS services specified to facilitate the control ofthe GA-PSR connection for user data transfer. Given that the GTP-U userdata transport is extended to the FAP in GAN solution for Femtocellsupport, these procedures are tightly integrated with RAB Assignmentprocedures for user data. GTP-U based connection between the FAP and theSGSN for user data transfer is referred to as the GA-PSR TransportChannel.

The GA-PSR Transport Channel consists of the following: (1) The IPaddress and destination UDP port number to be used for user datatransfer at both the SGSN and FAP, and (2) The GA-PSR TC Timer. The FAPor INC will activate a GA-PSR Transport Channel only when needed; i.e.,when the user data transfer is initiated.

The GA-PSR maintains a separate PS entity for each PDP context that isestablished. Each individual GA-PSR PS entity can be in two differentstates, GA-PSR-PS-STANDBY or GA-PSR-PS-ACTIVE state. The state of theGA-PSR PS entity and the corresponding transport channel are alwayssynchronized.

In GA-PSR-PS-STANDBY state the FAP is not able to send or receive userdata associated with the specific PDP context to and from the SGSN. TheINC or the FAP needs to activate the GA-PSR Transport Channel beforesending any user data for that PDP context. In this state acorresponding GA-PSR Transport Channel does not exist. When the GA-PSRTransport Channel is activated, the GA-PSR entity associated with thatPDP context enters the GA-PSR-PS-ACTIVE state.

In GA-PSR-PS-ACTIVE state the FAP and UE are able to send and receiveuser data associated with the specific PDP context to and from the SGSN.Furthermore there exists a corresponding GA-PSR Transport Channel forthis FAP/UE.

A GA-PSR TC Timer is also defined to control the transition fromGA-PSR-PS-ACTIVE to GA-PSR-PS-STANDBY state as follows. The FAP GA-PSRlayer implements a timer associated with each GA-PSR Transport Channel.The timer is started when that entity enters GA-PSR-PS-ACTIVE state andrestarted each time a data packet for that PDP context is transmitted toor received from the network. When the timer expires, the FAPdeactivates the GA-PSR Transport Channel and the corresponding PDPservice entity enters GA-PSR-PS-STANDBY state.

The GA-PSR TC Timer value is provided to the FAP as part of theFemtocell Registration procedure (i.e., in GA-RC REGISTER ACCEPTmessage).

2. FAP Initiated GA-PSR Transport Channel Activation

FIG. 34 depicts the FAP initiated GA-PSR Transport Channel activationprocedure of some embodiments. Initially, the corresponding GA-PSR PSPDP entity is in GA-PSR-PS-IDLE state when the uplink data transfer forthat PDP context is requested. The FAP has to establish the GA-PSRTransport channel prior to resuming the uplink data transfer.

As shown, if the RRC connection does not exist, the UE 3405 initiates(in Step 1) RRC Connection establishment procedure as per standard 3GPPprocedure. Upon successful RRC Connection establishment, the UE 3405forwards (in Step 2) a Service Request message to the SGSN via the FAP3410 indicating data transfer. The FAP performs (in Step 2 a) the GA-PSRConnection Establishment procedure with the INC as described in “FAPinitiated GA-PSR connection establishment” Subsection under “ResourceManagement” Section, above.

The FAP 3410 then encapsulates the request within theGA-PSR-UPLINK-DIRECT-TRANSFER message and forwards (in Step 3) therequest to the INC 3415. The INC forwards (in Step 4) the ServiceRequest to the CN (SGSN) 3420 encapsulated within the Initial Iu Messageor within the Direct Transfer message depending on PMM state.Optionally, the CN (SGSN) may initiate (in Step 5) security function asspecified in “Security Mode Control” Subsection and “Core networkauthentication” Subsections under “Femtocell Security” Section, furtherbelow. Optionally, upon receiving the request and if the UE was inPMM-CONNECTED state, the CN (SGSN) responds (in Step 6) with a ServiceAccept message.

Optionally, if the Service Accept message was received, the INC 3415forwards (in Step 7) the message to the FAP 3410. The FAP then forwards(in Step 8) the message to the UE 3405. The CN (SGSN) 3420 initiates (inStep 9) RAB Assignment procedure and includes the RAB-ID, the CNTransport Layer Address (IP address) and the CN Iu Transport Association(GTP-U Terminal Endpoint Identifier (TEID)) for user data to be usedwith this GA-PSR Transport Channel.

Next, the INC forwards (in Step 10) the GA-PSR ACTIVATE TC REQ to theFAP to activate the Transport Channel for user data transfer. Themessage includes the RAB-ID, and the INC IP Address and INC TEID. Toallow the FAP to send GA-PSR TC packets (i.e., GTP-U messages) directlyto the SGSN, the INC sets the INC IP Address to the CN IP Address andthe INC TEID to the CN TEID. In an alternate embodiment, it is possiblefor the GANC to assume the role of a GTP-U proxy gateway, where twoseparate GTP-U tunnels exist for a given GA-PSR TC i.e. first GTP-Ubetween FAP and GANC and the corresponding GTP-U between the GANC andthe SGSN. The GANC is responsible for relaying the actual PS datapackets between the two GTP-U tunnels. Next, corresponding Radio Bearersare established (in Step 11) between the FAP 3410 and UE 3405.

The FAP then responds (in Step 12) to the INC with acknowledgment. Themessage includes the RAB-ID and a GTP-U TEID assigned by the FAP for thespecific PS session. Upon receiving the acknowledgment, the INC sends(in Step 13) the RAB Assignment Rsp message to the CN (SGSN) to completethe RAB Assignment procedure. To allow the SGSN to send GTP-U messagesdirectly to the FAP, the INC sets the RAN IP Address to the FAP's IPAddress and the RAN TEID to the TEID allocated by the FAP for the UEspecific PS session.

The INC notifies (in Step 14) the FAP that the procedure is complete andthe FAP modifies the state of the corresponding GA-PSR PS PDP entity toGA-PSR-PS ACTIVE and starts GA-PSR PS TC Timer. The UE initiates (inStep 15) uplink user data transfer via the established transport channeland the SGSN may use the same transport channel to send downlink userdata packets. While the transport channel is active, both FAP and SGSNcan continue sending user data associated with the same PDP contextdirectly using this transport channel.

3. FAP Initiated Deactivation of the GA-PSR Transport Channel

FIG. 35 illustrates the scenario in some embodiments when the FAPdeactivates the GA-PSR Transport Channel after the GA-PSR TC Timerexpires. As shown, GA-PSR TC Timer associated with one of the activeGA-PSR Transport Channels expires (in Step 1). The FAP 3510 sends (inStep 2) GA-PSR DEACTIVATE TC REQ message to the INC 3515 including theRAB-ID to identify the GA-PSR Transport Channel and indicating thenormal release as a cause for deactivation.

The INC 3515 forwards (in Step 3) RAB Release Req message to the CN(SGSN) 3520 to request the release of the associated RAB. The CN (SGSN)responds (in Step 4) with the RAB Assignment Request indicating releasefor the requested RAB.

Next, the INC 3515 responds (in Step 5) to the FAP with a GA-PSRDEACTIVATE TC ACK message to acknowledge successful deactivation. Uponreceiving acknowledgment message, the FAP initiates (in Step 6) releaseof the associated Radio Bearers. Finally, the INC sends (in Step 7) RABAssignment Rsp message to notify the SGSN that the RAB Release procedureis complete.

4. Network Initiated Transport Channel Activation for PS Service

FIG. 36 depicts a scenario when the CN (SGSN) initiates activation of aPS Transport Channel for user data service. This scenario covers thecase when the SGSN receives a downlink user data packet from the GGSNand the RAB for that PDP context is not established. Initially, the CN(SGSN) received downlink user data to transfer to the UE and theassociated RAB is not established. The UE is in PMM-IDLE state. The UE3605 is in PMM-IDLE state and the CN (SGSN) 3610 sends (in Step 1) theRANAP Paging request to the UE 3605 via the INC 3615 to locate the user.The paging request indicates paging for PS Domain. The INC 3615 forwards(in Step 2) the GA-PSR PAGING message to the FAP 3610.

Next, the FAP forwards (in Step 3) the PS Page to the UE 3605 as perstandard 3GPP procedure. The FAP may use Paging Type 1 or 2 based on theRRC state of the UE as described in TS 25.331. Next, an RRC connectionis established (in Step 4) between the UE 3605 and FAP 3610. This stepis omitted if there is an already existing RRC connection (e.g. a RRCconnection may have been established for CS domain)

Next, the UE responds (in Step 5) to the SGSN via the FAP with a Servicerequest indicating PS paging response. The message is encapsulatedwithin the RRC INITIAL DIRECT TRANSFER message. The FAP performs (inStep 5 a) the GA-PSR Connection Establishment procedure with the INC asdescribed in Subsection “FAP initiated GA-PSR connection establishment”under “RESOURCE MANAGEMENT” Section, above. The FAP forwards (in Step 6)the PS paging response to the INC using GA-PSR PAGING RESPONSE message.

The INC forwards (in Step 7) the Service Request message to the SGSNencapsulated in the RANAP Initial UE Message. Security function isperformed (in Step 8) as specified in “Security mode control” Subsectionand “Core network authentication” under “FEMTOCELL SECURITY” Section,below. Steps 9 to 15 are same as described in the “FAP initiated GA-PSRtransport channel activation” Subsection, above.

5. Network Initiated Transport Channel Deactivation

FIG. 37 depicts a network initiated GA-PSR Transport Channeldeactivation procedure that includes Radio Access Barer release in someembodiments. Initially, active GA-PSR Transport Channel associated withthe UE 3705 that is registered for Femtocell service is active.

As shown, optionally, the INC 3715 may initiate (in Step 1) RAB Releaseprocedure as a result of error handling procedure. This would trigger CN(SGSN) 3720 to release the corresponding RAB. The CN (SGSN) 3720 sends(in Step 2) a RAB Assignment Request to request the release of theassociated RAB. The release request may include one or more RABs.

The INC 3715 requests (in Step 3) deactivation of the associated GA-PSRTransport Channel. As a result, the corresponding Radio Bearers are (inStep 4) released. The FAP 3710 then updates (in Step 5) the state of thecorresponding GA-PSR PS PDP entity to STANDBY, stops GA-PSR TC Timer andsends the acknowledgment back to the INC. Steps 3, 4 and 5 are repeatedfor each additional RAB that needs to be released. Finally, the INC 3715notifies (in Step 6) the CN (SGSN) 3720 that the release was successful.

B. User Data and Signaling Transport

1. User Data Transport Procedures

FIG. 38 illustrates the transport of user data packets via Femtocell insome embodiments. As shown, if the corresponding GA-PSR TransportChannel is not active, the GA-PSR TC activation procedure is initiated(in Step 1) as specified in the “FAP initiated GA-PSR transport channelactivation” Subsection, above. Upon the GA-PSR Transport Channelestablishment, the FAP 3810 starts (in Step 2) GA-PSR TC Timer.

The UE 3805 initiates (in Step 3) the transfer of an uplink user datapacket using PDCP Data service. The FAP 3810 forwards (in Step 4) thepacket using the standard GTP-U protocol as specified in “GPRSTunnelling Protocol (GTP) across the Gn and Gp interface”, 3GPP TS29.060, and restarts (in Step 5) GA-PSR TC Timer.

The CN (SGSN) 3820 transfers (in Step 6) downlink user data packetutilizing the same GA-PSR Transport Channel associated with the specificPDP context. Downlink user data packets are transferred using thestandard GTP-U protocol as specified in 3GPP TS 29.060. Upon receivingthe downlink data packet, the FAP restarts (in Step 7) GA-PSR TC Timerassociated with the corresponding GA-PSR Transport Channel and forwards(in Step 8) the packet to the UE via the PDCP.

Additional uplink and downlink user data packets are transferred (inStep 9) via the same GA-PSR Transport Channel as described in steps 2and 3 respectively. After the GA-PSR TC Timer expires (Step 10), the FAPinitiates (in Step 11) GA-PSR Transport Channel deactivation procedureas described in the “FAP initiated deactivation of the GA-PSR transportchannel” Subsection, above. A FAP with local service can support PS userplane activity using the FAP IMSI. The necessary message flows would besimilar as above without the FAP-UE message exchanges over the airinterface.

2. GA-PSR Signaling Procedures

A single TCP connection per UE is established for the transport ofsignaling messages within the Femtocell. This TCP connection is used totransport all CS and PS related signaling and SMS messages.

a) UE Initiated PS Signaling Procedure

For UE initiated PS related signaling, the UE sends a PS signalingmessage to the CN, via the INC which forwards it to the CN over theIu-ps interface as per standard UMTS; e.g. the signaling message mayinclude GMM attach or SM PDP context activation message. The INCencapsulates the received signaling message within a RANAP DirectTransfer message that is forwarded to the SGSN over the Iu-ps interface.FIG. 39 illustrates Uplink Control Plane Data Transport of someembodiments.

Initially, the UE 3905 is ready to send an uplink signaling message forPS services to the CN (SGSN) 3920. This could be any of the GMM or SMsignaling messages. As shown, if the RRC connection does not exist, theUE 3905 initiates (in Step 1) RRC Connection establishment procedure asper standard 3GPP procedure.

Upon successful RRC Connection establishment, the UE forwards (in Step2) a Service Request message to the SGSN via the FAP 3910 indicating PSSignaling message. The FAP performs (in Step 2 a) the GA-PSR ConnectionEstablishment procedure with the INC as described in the “FAP initiatedGA-PSR connection establishment” Subsection under the “RESOURCEMANAGEMENT” Section, above. The FAP encapsulates the Service Requestwithin the GA-PSR-UPLINK-DIRECT-TRANSFER message and forwards (in Step3) the request to the INC 3910.

Next, the INC forwards (in Step 4) the Service Request to the SGSNencapsulated within the Initial Iu Message or within the Direct Transfermessage depending on PMM state. Optionally, the CN (SGSN) may initiate(in Step 5) security function as specified in Sections “Security ModeControl” and “Core Network Authentication”, below. The UE 3805 sends (inStep 6) the PS signaling message to the FAP 3910 using RRC Uplink DirectTransfer service.

The FAP 3910 forwards (in Step 7) the PS signaling message to the INCencapsulated within the GA-PSR-UPLINK-DIRECT-TRANSFER message. Finally,the INC 3915 forwards (in Step 8) the PS signaling message to the CN(SGSN) 3920 using RANAP Direct Transfer procedure.

b) Network Initiated PS Signaling Procedure

For Network initiated PS related signaling, the Core Network sends a PSsignaling message to the INC via the IuPS interface as per standardUMTS; e.g. the signaling message may include GMM attach accept or SM PDPcontext activation accept message. The INC encapsulates the receivedsignaling message within a GA-PSR-DOWNLINK-DIRECT-TRANSFER OR GA-PSRPAGING message that is forwarded to the FAP via the existing TCPsignaling connection. FIG. 40 illustrates Downlink Control Plane DataTransport of some embodiments. Initially, the CN (SGSN) 4020 is ready tosend a downlink signaling message for PS services to the UE 4005. Thiscould be any of the GMM or SM signaling messages. Given that thesignaling procedure is network initiated and if the UE is in PMM-IDLEstate, the SGSN will first page the UE. If the UE is in PMM-CONNECTEDstate the SGSN will send the downlink PS signaling message using RANAPDirect Transfer procedure starting with Step 9.

As shown, optionally, if the UE 4005 is in PMM-IDLE state, the CN (SGSN)4020 sends (in Step 1) the RANAP Paging request to the UE via the INC4015 to locate the user. The paging request indicates paging for PSDomain. Optionally, if the paging request was received, the INC forwards(in Step 2) the paging request using the GA-PSR PAGING message to theFAP 4010.

Also, optionally, if the paging message is received, the FAP forwards(in Step 3) the PS page to the UE as per standard 3GPP procedure.Optionally, if the RRC connection does not exist for that UE, it isestablished (in Step 4) as per standard 3GPP procedure. Optionally, ifthe page for PS services was received, the UE responds (in Step 5) tothe SGSN via the FAP with a Service Request message indicating PS pagingresponse. The Service Request message is encapsulated within the RRCINITIAL DIRECT TRANSFER message.

The FAP 4010 performs (in Step 5 a) the GA-PSR Connection Establishmentprocedure with the INC as described in the “FAP initiated GA-PSRconnection establishment” Subsection under the “RESOURCE MANAGEMENT”Section, above. The FAP forwards (in Step 6) the response encapsulatedwithin the GA-PSR PAGING RESPONSE message to the INC.

Next, the INC 4015 forwards (in Step 7) the Service Request message tothe SGSN 4020 encapsulated in the RANAP Initial UE Message. Optionally,the CN (SGSN) initiates (in Step 8) Security Function.

The CN (SGSN) forwards (in Step 9) the PS signaling message to the INCusing RANAP Direct Transfer procedure. The INC forwards (in Step 10) thePS signaling message to the FAP encapsulated within theGA-PSR-DOWNLINK-DIRECT-TRANSFER message. Finally, the FAP sends (in Step11) the signaling message to the UE using RRC Downlink Direct Transferservice. A FAP with local service can support PS signaling planeactivity using the FAP IMSI. The necessary message flows would besimilar as above without the FAP-UE message exchanges over the airinterface.

VIII. ERROR HANDLING PROCEDURES

In some embodiments, the checks described in this section are applied toall messages exchanged in the Femtocell system. This section alsospecifies procedures for the handling of unknown, unforeseen, anderroneous protocol data by the receiving entity. These procedures arecalled “error handling procedures”, but in addition to providingrecovery mechanisms for error situations they define a compatibilitymechanism for future extensions of the protocols. In some embodiments,Sub-sections A to F, below, are applied in order of precedence.

In this section the following terminology is used (1) An informationelement (IE) is defined to be syntactically incorrect in a message if itincludes at least one value defined as “reserved” in the correspondingmessage, or if its value part violates rules of any correspondingmessages. However it is not a syntactical error that an IE specifies inits length indicator a greater length than defined in for the specificmessage, and (2) A message is defined to have semantically incorrectcontents if it includes information which, possibly dependent on thestate of the receiver, is in contradiction to the resources of thereceiver and/or to the procedural part of this specification. Theprocedures described in this sub-section apply to both GA-CSR and GA-PSRmessages, unless explicitly specified otherwise.

A. Message Too Short

When a message is received that is too short to include a completemessage header and all the mandatory information elements, that messageis ignored.

B. Invalid Message Header

When the FAP receives a message over UDP with message type not definedor not implemented, the FAP ignores the message. When the FAP receives amessage over TCP with protocol discriminator not defined or notimplemented, the FAP ignores the message. When the FAP receives amessage with Skip Indicator IE not encoded as 0000 or Length IE greaterthan 2048, the FAP ignores the message.

When the FAP receives a message over TCP with message type not definedfor the specific PD (GA-CSR or GA-PSR) or not implemented, the FAPreturns a GA-CSR STATUS or GA-PSR STATUS respectively, with cause“message type non-existent or not implemented”. When the FAP receives amessage not compatible with the protocol state, the FAP ignores themessage and shall return a (GA-CSR or GA-PSR) STATUS message with cause“Message type not compatible with protocol state”.

C. Invalid Information Elements

When the FAP receives a GA-RC OR GA-CSR OR GA-PSR message with a missingor syntactically incorrect mandatory IE, the FAP ignores the message andreturns a (GA-RC or GA-PSR) STATUS message with cause “Invalid mandatoryinformation”. The FAP also ignores all unknown IEs in received messages.The FAP further treats all optional IEs that are syntactically incorrectin a message as not present in the message.

When the FAP diagnoses a missing or unexpected conditional IE or when itreceives at least one syntactically incorrect conditional IE, the FAPignores the message and returns a (GA-RC or GA-PSR) STATUS message withcause value “conditional IE error”. When the FAP receives a message withsemantically incorrect contents, the FAP ignores the message and returnsa (GA-RC or GA-PSR) STATUS message with cause value “semanticallyincorrect message”.

D. Handling of Lower Layer Faults

The handling of lower layer failures in the FAP while in theGA-RC-DEREGISTERED state is as follows. If a TCP connection wasestablished towards the Provisioning GANC, the FAP releases theconnection. If a secure connection was established towards SeGW of theProvisioning GANC, the FAP releases the secure connection (as defined in“Internet Key Exchange (IKEv2) Protocol”, IETF RFC 4306. additionally,when the lower layer failures happen during a Discovery procedure, theFAP doubles the current timer value for TU3903 but not exceeding themaximum value (32 minutes). The FAP also starts timer TU3903.

When the lower layer failures happen during a Registration procedure,and if the registration is still unsuccessful after a number of attemptsdefined the FAP parameter “Up Connect Attempt Count” (maximum value of3), and if the FAP had attempted the registration towards the DefaultGANC, then the FAP deletes the stored information about the DefaultGANC, increments Redirection Counter, and initiates the DiscoveryProcedure. When the lower layer failures happen during a Registrationprocedure, the registration is still unsuccessful after a number ofattempts defined the FAP parameter “Up Connect Attempt Count” (maximumvalue of 3), and the FAP had attempted the registration towards aServing GANC, then the FAP increments Redirection Counter and initiatesRegistration Procedure towards the Default GANC.

When the lower layer failures happen during a Registration procedure andthe registration is successful before a number of attempts defined theFAP parameter “Up Connect Attempt Count” (maximum value of 3), then theFAP starts timer TU3905 and waits for it to expire.

The handling of lower layer failures in the FAP while not in theGA-RC-DEREGISTERED state is as follows. For all lower layer failures inthe FAP (for example related to DNS, IPSec or TCP failures other thanRST) except the TCP connection failure which is handled as described inthe “FAP initiated FAP Synchronization after TCP connectionreestablishment” sub-section described above, the FAP (1) releases theTCP connection towards the current GANC, if established, (2) releasesthe secure connection towards SeGW of the current GANC, if established,(3) starts timer TU3905 (for FAP TCP connection) or TU3955 (for UEspecific TCP connection), and (4) enters GA-RC-DEREGISTERED state.

E. Out of Sequence IEs

The FAP ignores all out of sequence IEs in a message. In someembodiments, the GANC also takes the same approach and ignores all outof sequence IEs in a message.

F. Unexpected Messages

The FAP silently discards all unexpected messages (unless specificbehavior is defined for certain messages) which are either inconsistentwith the current state of the device or out of sequence. The networkshould take the same approach.

IX. MESSAGE AND INFORMATION ELEMENTS USED

This section provides a list of messages and Information elements (IEs)used in some embodiments. IEs are similar to “attributes” or“parameters” and are used in messages to exchange information acrossinterfaces.

Table IX-1 summarizes the messages for Generic Resources management.

TABLE IX-1 Messages for Unlicensed Radio Resources management Discoverymessages: GA-RC DISCOVERY REQUEST GA-RC DISCOVERY ACCEPT GA-RC DISCOVERYREJECT Registration messages: GA-RC REGISTER REQUEST GA-RC REGISTERACCEPT GA-RC REGISTER REDIRECT GA-RC REGISTER REJECT GA-RC DEREGISTERGA-RC REGISTER UPDATE UPLINK GA-RC REGISTER UPDATE DOWNLINKMiscellaneous message: GA-RC KEEP ALIVE GA-RC SYNCHRONIZATIONINFORMATION

Table IX-2 summarizes the messages for Generic Access Circuit SwitchedResources (GA-CSR) management

TABLE IX-2 Messages for GA-CSR management GA-CSR connectionestablishment messages: GA-CSR REQUEST GA-CSR REQUEST ACCEPT GA-CSRREQUEST REJECT Traffic Channel establishment messages: GA-CSR ACTIVATECHANNEL GA-CSR ACTIVATE CHANNEL ACK GA-CSR ACTIVATE CHANNEL FAILUREGA-CSR ACTIVATE CHANNEL COMPLETE Channel release messages: GA-CSRRELEASE GA-CSR RELEASE COMPLETE GA-CSR CLEAR REQUEST Paging messages:GA-CSR PAGING REQUEST GA-CSR PAGING RESPONSE Security Mode messages:GA-CSR SECURITY MODE COMMAND GA-CSR SECURITY MODE COMPLETE GA-CSRSECURITY MODE REJECT Miscellaneous messages: GA-CSR UPLINK DIRECTTRANSFER GA-CSR DOWNLINK DIRECT TRANSFER GA-CSR STATUS

Table IX-3 summarizes the messages for Generic Access Packet ServicesResource (GA-PSR) management.

TABLE IX-3 Messages for Generic Access Radio Link Control managementTransport Layer used GA-PSR Connection Management messages:GA-PSR-REQUEST TCP GA-PSR REQUESTACCEPT TCP GA-PSR REQUEST REJECT TCPGA-PSR-RELEASE TCP GA-PSR RELEASE COMPLETE TCP GA-PSR TC Managementmessages: GA-PSR-ACTIVATE-TC-REQ TCP GA-PSR-ACTIVATE-TC-ACK TCPGA-PSR-ACTIVATE-TC-CMP TCP GA-PSR-DEACTIVATE-TC-REQ TCPGA-PSR-DEACTIVATE-TC-ACK TCP GPRS Tunneling messages:GA-PSR-UPLINK-DIRECT-TRANSFER TCP GA-PSR-DOWNLINK-DIRECT-TRANSFER TCPGAN Specific Signaling messages: GA-PSR-PAGING TCP GA-PSR-PAGINGRESPONSE TCP GA-PSR-STATUS TCP Security messages: GA-PSR SECURITY MODECOMMAND TCP GA-PSR SECURITY MODE COMPLETE TCP GA-PSR SECURITY MODEREJECT TCP GA-PSR CLEAR REQUEST TCP

TABLE 9.2.1 IE type and identifiers for Unlicensed Radio Resourcesmanagement IE Identifier Mobile Identity (FAP) 1 GAN Release Indicator 2Access Identity 3 GERAN Cell Identity 4 Location Area Identification 5GERAN/UTRAN coverage Indicator 6 GAN Classmark 7 Geographical Location 8GANC-SeGW IP Address 9 GANC-SeGW Fully Qualified Domain/Host Name 10Redirection Counter 11 Discovery Reject Cause 12 GAN Cell Description 13GAN Control Channel Description 14 Cell Identifier List 15 TU3907 Timer16 GSM RR/UTRAN RRC State 17 Routing Area Identification 18 GAN Band 19GA-RC/GA-CSR State 20 Register Reject Cause 21 TU3906 Timer 22 TU3910Timer 23 TU3902 Timer 24 L3 Message 26 Channel Mode 27 Mobile StationClassmark 2 28 RR Cause 29 Cipher Mode Setting 30 GPRS Resumption 31Handover From GAN Command 32 UL Quality Indication 33 TLLI 34 PacketFlow Identifier 35 Suspension Cause 36 TU3920 Timer 37 QoS 38 GA-PSRCause 39 User Data Rate 40 Routing Area Code 41 AP Location 42 TU4001Timer 43 Location Status 44 Cipher Response 45 Ciphering Command RAND 46Ciphering Command MAC 47 Ciphering Key Sequence Number 48 SAPI ID 49Establishment Cause 50 Channel Needed 51 PDU in Error 52 Sample Size 53Payload Type 54 Multi-rate Configuration 55 Mobile Station Classmark 356 LLC-PDU 57 Location Black List indicator 58 Reset Indicator 59 TU4003Timer 60 AP Service Name 61 GAN Service Zone Information 62 RTPRedundancy Configuration 63 UTRAN Classmark 64 Classmark Enquiry Mask 65UTRAN Cell Identifier List 66 Serving GANC table indicator 67Registration indicators 68 GAN PLMN List 69 Required GAN Services 71Broadcast Container 72 3G Cell Identity 73 FAP Radio Identity 96 GANC IPAddress 97 GANC Fully Qualified Domain/Host Name 98 IP address for GPRSuser data transport 99 UDP Port for GPRS user data transport 100 GANCTCP port 103 RTP UDP port 104 RTCP UDP port 105 GERAN Received SignalLevel List 106 UTRAN Received Signal Level List 107 Integrity ProtectionInformation 75 Encryption Information 76 Key Status 77 Chosen IntegrityAlgorithm 78 Chosen Encryption Algorithm 79 Security Mode Reject Cause80 RAB ID 81 RAB Parameters 82 GTP TEID 83 Service Handover 84 PDP TypeInformation 85 Data Volume Reporting Indicator 86 DL GTP-PDU SequenceNumber 86 UL GTP-PDU Sequence Number 88 DL N-PDU Sequence Number 89 ULN-PDU Sequence Number 90 Alternate RAB Parameter Values 91 Assigned RABParameter Values 92 Data Volume List 93 DRX Cycle Length Coefficient 94Paging Cause 95 URA Identity 110 GA-PSR State 111 Mobile Identity (UE)112 RABS Data Volume Report List 113 Allocation/Retention PriorityInformation 114 NAS Synchronization Indicator 115

X. SHORT MESSAGE SERVICES

The Femtocell system provides support for both circuit mode (CS mode)and packet mode (PS mode) SMS services. CS/PS mode of operation UEs maybe able to send and receive short messages using either the MM sub-layeror the GMM sub-layer. PS mode of operation UEs may be able to send andreceive short messages using only GMM sub-layer. Inter-working withFemtocell related to SMS services is described in the followingsections.

A. Circuit Mode (CS Mode) SMS Services

The Femtocell protocol architecture related to CS mode SMS supportbuilds on the circuit services signaling architecture described in the“CS domain—control plane architecture” Subsection under the “FEMTOCELLSYSTEM ARCHITECTURE” Section, above. FIG. 41 illustrates the protocolarchitecture for CS mode SMS in some embodiments.

The Femtocell CS mode SMS support is based on the same mechanism that isutilized for CS mobility management and call control. On the UE 4105side, the SMS layers 4110 (including the supporting CM sub-layerfunctions) utilize the services of the MM layer 4115 to transfer SMSmessages per standard circuit mode implementation. The SM-CP protocol iseffectively tunneled between the UE 4105 and the MSC 4115 using themessage relay functions in the GA-CSR protocol. As with CS mobilitymanagement and call control procedures, SMS uses the UE specific TCPsignaling connection between the FAP and the INC 4120, providingreliable SMS delivery over the Up interface 4125.

B. Packet Mode (PS Mode) SMS Services

The Femtocell protocol architecture related to PS mode SMS supportbuilds on the packet services signaling architecture described in the“PS domain—control plane architecture” Subsection under the “FEMTOCELLSYSTEM ARCHITECTURE” Section, above. FIG. 42 illustrates the GANprotocol architecture for packet mode SMS in some embodiments.

On the UE 4205 side, the SMS layers 4210 (including the supporting CMsublayer functions) utilize the services of the GMM layer 4215 totransfer SMS messages per the standard packet mode implementation. TheSM-CP protocol is effectively tunneled between the UE 4205 and the SGSN4220 using the message relay functions in the GA-PSR protocol. As withthe packet services signaling procedures, SMS uses the UE specific TCPsignaling connection between the FAP and the INC 4225, providingreliable SMS delivery over the Up interface 4230.

C. SMS Scenarios

The following scenarios illustrate the message flows involved forvarious SMS scenarios via the Femtocell.

1. Circuit Mode Mobile-Originated SMS

FIG. 43 illustrates a mobile originated SMS transfer via GAN circuitmode in some embodiments. As shown, the user enters a message andinvokes the mobile-originated SMS function on the UE 4305 in idle mode.Steps 4 to 10 in FIG. 43 are Steps 2 to 7 in the “Mobile originatedcall” Subsection under the “CALL MANAGEMENT” Section, above. Next, theUE 4305 sends (in Step 8) the SMS message encapsulated in a CP-DATAmessage to the FAP 4310 over the air interface.

The FAP relays (in Step 9) the CP-DATA message encapsulated in a GA-CSRUL DIRECT TRANSFER message to the INC 4315. The INC forwards (in Step10) the CP-DATA message to the MSC 4320 using RANAP Direct Transfermessage. The MSC forwards (in Step 11) the message to the SMSC via theSMS interworking MSC (IWMSC) 4325 using the MAP-MO-FORWARD-SM Invokemessage.

The MSC sends (in Step 12) CP-DATA-ACK to acknowledge the receipt of theCP-DATA message. The SM-CP is designed in a way that every CP-DATA blockis acknowledged on each point-to-point connection between the UE andSMSC (SM Service Center) to ensure that the under-laying transport layer(in this case RANAP) works error free since there is no explicit ack toa RANAP Direct Transfer message.

The INC 4315 relays (in Step 13) the acknowledgement to the FAP 4310.The FAP forwards (in Step 14) the CP-DATA-ACK to the UE 4305 over theair interface. The SMSC sends (in Step 15) a SMS message in response tothe IWMSC and the IWMSC sends the response to the MSC in theMAP-MO-FORWARD-SM Return Result message.

Next, the MSC 4320 relays the response (in Step 16) to the INC 4315 inthe CP-DATA message. The INC 4315 relays (in Step 17) this to the FAP4310 using GA-CSR DL DIRECT TRANSFER. The FAP relays (in Step 18) theresponse to the UE over the air interface using the existing RRCconnections.

As part of SM-CP ack process, the UE acknowledges (in Step 19) thereceipt of CP-DATA to the FAP. The FAP relays (in Step 20) theacknowledgement to the INC. The INC forwards (in Step 21) theacknowledgement to the MSC using the RANAP Direct Transfer message.

Next, the MSC 4320 sends (in Step 22) Iu Release message to the INCindicating a request to release the session resources. The SCCPConnection Identifier is used to determine the corresponding session.The INC 4315 in turn releases (in Step 23) the GA-CSR connection to theFAP for the specific session. Also, the FAP 4310 releases (in Step 24)corresponding radio resources towards the UE. Finally, the INCacknowledges (in Step 25) the release in an Iu Release Complete messageto the MSC. The SCCP connection associated with the call between the INCand the MSC is released.

2. CS Mode Mobile-Terminated SMS

FIG. 44 illustrates a CS mode mobile terminated SMS transfer viaFemtocell in some embodiments. As shown, the SMSC 4425 sends (in Step 1)a SMS message destined for the UE 4405 to the SMS gateway MSC (GMSC)4420. The GMSC queries the HLR for routing information using theMAP-SEND-ROUTING-INFO-SM Invoke message.

The HLR responds (in Step 2) with the MSC number associated with theserving MSC. The SMS GMSC delivers (in Step 3) the SMS message to theMSC using the MAP MT-FORWARD-SM Invoke message. Steps 4 to 10 are thesame as Steps 2 to 8 in “Mobile Terminated Call” Section above, exceptthat the user is attempting to terminate an SMS message; therefore, onlya signaling channel is necessary.

Next, the MSC 4420 sends (in Step 11) the SMS message encapsulated in aCP-DATA message to the INC 4415. The INC relays (in Step 12) this to theFAP 4410 using GA-CSR DL DIRECT TRANSFER. The FAP relays (in Step 13)the CP-DATA message to the UE 4405 over the air interface using theexisting RRC connections.

As part of SM-CP ack process, the UE acknowledges (in Step 14) thereceipt of CP-DATA to the FAP. The FAP relays (in Step 15) theacknowledgement to the INC. The INC forwards (in Step 16) theacknowledgement to the MSC using the RANAP Direct Transfer message.

The SMS entity on the UE acknowledges (in Step 17) the SMS message viaanother CP-DATA message (response) which is sent to the FAP over the airinterface. The FAP relays (in Step 18) the response CP-DATA messageencapsulated in a GA-CSR UL DIRECT TRANSFER message to the INC. The INCforwards (in Step 19) the response CP-DATA message to the MSC usingRANAP Direct Transfer message.

Next, the MSC 4420 sends the response (in Step 20) to the SMS GMSC 4425in the MAP-MT-FORWARD-SM Return Result message. The GMSC relays theresponse to the SMSC. The MSC acknowledges (in Step 21) the receipt ofCP-DATA to the INC. The INC 4415 relays (in Step 22) the CP-DATA-ACK tothe FAP.

Next, the FAP 4410 forwards (in Step 23) the CP-DATA-ACK to the UE 4405over the air interface. The MSC 4420 sends (in Step 24) Iu Releasemessage to the INC 4415 indicating a request to release the sessionresources. The SCCP Connection Identifier is used to determine thecorresponding session.

The INC 4415 in turn releases (in Step 25) the GA-CSR connection to theFAP for the specific session. The FAP releases (in Step 26)corresponding radio resources towards the UE. The INC acknowledges (inStep 27) the release in an Iu Release Complete message to the MSC. TheSCCP connection associated with the call between the INC and the MSC isreleased XI. EMERGENCY SERVICES

Transparent support for emergency services is a key regulatoryrequirement. Femtocell emergency services support capabilities includesupport for flexible UMTS-to-Femtocell SAI mapping and INC assignmentfunctionality. This allows the FAP to be assigned to an INC that is, inturn, connected to an MSC that can route calls to the PSAP in theFemtocell service area. It also allows the service provider to defineFemtocell service areas that align with macro network service areas, toleverage the existing service area based PSAP routing approach.

Femtocell emergency services support capabilities also include supportfor the retrieval and storage of FAP location information from anexternal database, using the enhanced service access control functions.Femtocell emergency services support capabilities further includesupport for the RANAP Location Report procedure, by which the INCreturns the FAP location information to the MSC during emergency callprocessing. Some embodiments do not support emergency calling from anun-authorized UE over a given FAP (due to the Service Access Control forthe specific FAP).

One of the functions of the UMTS-Femtocell mapping process is to assigna Femtocell Service Area for calls made by the UE using the Femtocell.The FAP, during registration, provides information on macro coverage(such as macro LAI, macro 3G cell-id, etc) which can be mapped to aFemtocell Service Area Identification (SAI). This Femtocell SAI can beused to support the ability to route emergency calls to the correctPSAP; i.e., based on SAI. However, to meet the requirement to route theemergency call to the correct PSAP, there are actually two possibleapproaches: (1) Service Area (i.e. SAI) Based Routing, and (2) LocationBased Routing.

A. Service Area Based Routing

With Service Area Based Routing, the PSAP routing decision is based onthe Service Area Code (SAC) included within the SAI. FIG. 45 illustratesa service area based routing scenario of some embodiments. As shown, theuser originates (in Step 1) an emergency call using the UE 4505 campedon the Femtocell. The UE establishes (in Step 2) a RRC connection withthe FAP with the establishment cause of emergency call.

Upon request from the upper layers, the UE sends (in Step 3) the CMService Request (with CM Service Type set to “Emergency CallEstablishment”) to the FAP 4510. The FAP performs (in Step 4) the GA-CSRConnection Establishment procedure (with establishment cause indicatingan Emergency call) with the INC 4515 as described in previous sections.

The FAP 4510 then forwards (in Step 5) the CM Service Request to the INC4515 using a GA-CSR UL DIRECT TRANSFER message. The INC 4515 establishesa SCCP connection to the MSC 4520 and forwards (in Step 6) the CMService Request to the MSC 4520 using the RANAP Initial UE Message. Thisinitial message includes information about the location area (LAI) andservice area (SAI) assigned to the specific FAP over which the emergencycall was initiated.

The MSC 4520, INC 4515 and UE 4505 continue (in Step 7) callestablishment signaling. The MSC determines the serving PSAP based onthe service area of the calling UE and routes (in Step 8) the emergencycall to the appropriate PSAP. Additional signal messages are exchangedbetween the UE and PSAP and the emergency call is established (in Step9) between the UE and the appropriate serving PSAP.

B. Location Based Routing

One of the drawbacks service area based routing is that it would requirethat Femtocell service area be split into multiple service areas basedon PSAP routing requirements. The location based routing method removesthis limitation. Location based routing is also known as “X/Y routing”or “Routing by position” and is defined in “Location Services (LCS);Functional description; Stage 2”, 3GPP TS 23.271. Some embodimentssupport Location based routing while some other embodiments do notsupport Location based routing.

XII. FEMTOCELL SECURITY

GAN Femtocell supports security mechanisms at different levels andinterfaces as depicted in FIG. 46. As shown, the security mechanismsover the Up interface 4605 protect signaling, voice and data trafficflows between the FAP 4610 and the GANC SeGW 4615 from unauthorized use,data manipulation and eavesdropping; i.e. authentication, encryption anddata integrity mechanisms are supported.

Authentication of the subscriber by the core network occurs between theMSC/VLR or SGSN 4620 and the UE 4625 and is transparent to the GANC4640. The air interface between the UE 4625 and FAP 4610 is protectedvia encryption (ciphering) and integrity checks. In some embodiments theuse of ciphering on the air interface is optional.

Additional application level security mechanisms may be employed in thePS domain to secure the end-to-end communication between the FAP 4605and the application server 4630. For example, the FAP may run the HTTPprotocol over an SSL session for secure web access.

All signaling traffic and user-plane traffic sent between FAP and GANCover the Up interface 4605 is protected by a secure tunnel (e.g., anIPSec tunnel) between the FAP 4605 and GANC-SeGW 4615, that providesmutual authentication (using SIM or USIM credentials), encryption anddata integrity using the same mechanisms as specified in “3G security;Wireless Local Area Network (WLAN) interworking security”, 3GPP TS33.234 standard, hereinafter “TS 33.234 standard”. The use of a singlesecure tunnel between the FAP 4610 and the GANC 4640 enables multipleUEs 4625 (only one is shown in FIG. 46 for simplicity) as well as theFemtocell itself (e.g., the FAP signaling or when the FAP supports localservice using the FAP IMSI, the signaling and the user plane for the FAPutilize the same IPSec tunnel). The advantages of using a single IPSectunnel between the FAP and the GANC include relieving the SeGW fromsupporting a large number of secure tunnels.

A. Authentication

In some embodiments, the Up interface supports the ability toauthenticate the FAP with the GANC (for the purposes of establishing thesecure tunnel) using UMTS credentials. Authentication between FAP andGANC shall be performed using EAP-AKA or EAP-SIM within IKEv2.

The FAP and GANC-SeGW establish a security association for protectingsignaling traffic and user-plane (voice and data) traffic. The protocolfor authentication is IKEv2. Mutual authentication and key generation isprovided by EAP-AKA or EAP-SIM.

The basic elements of these procedures are the following. The FAPconnection with the GANC-SeGW is initiated by starting the IKEv2 initialexchanges (IKE_SA_INIT). The EAP-AKA or EAP-SIM procedure is started asa result of these exchanges. The EAP-SIM procedure for FAP with SIM onlyor FAP with USIM, but not capable of UMTS AKA, is performed between FAPand AAA server (that has access to the AuC/HLR/HSS to retrievesubscriber information). The EAP-AKA procedure for FAP with USIM and theFAP is capable of UMTS AKA, is performed between FAP and AAA server. TheGANC-SeGW acts as relay for the EAP-SIM/EAP-AKA messages.

When the EAP-AKA/EAP-SIM procedure has completed successfully, the IKEv2procedure can be continued to completion and the signaling channelbetween FAP and GANC-SeGW is secured. The FAP can then continue with thediscovery or registration procedure. Signaling flows for EAP-AKA/EAP-SIMauthentication are shown in the following subsection.

1. EAP-SIM Procedure for Authentication

The EAP-SIM authentication mechanism is specified in “ExtensibleAuthentication Protocol Method for GSM Subscriber Identity Modules(EAP-SIM)”, IETF RFC 4686. This section describes how this mechanism isused in Femtocell. FIG. 47 illustrates EAP-SIM authentication procedurein some embodiments. As shown, the FAP 4705 connects to the generic IPaccess network and obtains (in Step 1) the IP address of the Default orthe Serving SeGW via DNS query. In response, the DNS server 4710 returns(in Step 2) the IP address of the SeGW.

Next, the FAP 4705 initializes the IKEv2 authentication procedure bystarting (in Steps 3 a-3 c) the IKE_SA_INIT exchange. It indicates thedesire to use EAP by leaving out the AUTH payload from message 3, thefirst message of the IKE_AUTH exchange, and the initiator identity iscomposed compliant with the Network Access Identifier (NAI) formatspecified in “The Network Access Identifier”, IETF RFC 2486, hereinafter“IETF RFC 2486”, which includes the IMSI and an indication that EAP-SIMshould be used.

Next, the GANC-SeGW 4715 sends (in Step 4) an EAP Response/Identitymessage to the AAA server 4720, including the initiator identityincluded in the third IKE message. The leading digit of the NAIindicates that the FAP wishes to use EAP-SIM. The AAA server 4720identifies the subscriber as a candidate for authentication withEAP-SIM, based on the received identity, and verifies that EAP-SIM shallbe used based on subscription information. The AAA then sends (in Step5) the EAP Request/SIM-Start packet to GANC-SeGW 4715.

The GANC-SeGW forwards (in Step 6) the EAP Request/SIM-Start packet toFAP. The FAP chooses a fresh random number NONCE_MT. The random numberis used in network authentication. The FAP sends (in Step 7) the EAPResponse/SIM-Start packet, including NONCE_MT, to the GANC-SeGW.

The GANC-SeGW forwards (in Step 8) the EAP Response/SIM-Start packet tothe AAA Server. The AAA server 4720 requests (in Step 9) authenticationdata from the HLR 4725, based on the IMSI. The AAA server could insteaduse cached triplets previously retrieved from the HLR to continue theauthentication process.

Optionally, the AAA 4720 receives (in Step 10) user subscription andmultiple triplets from the HSS/HLR 4725. AAA server determines the EAPmethod (SIM or AKA) to be used, according to the user subscriptionand/or the indication received from the FAP. In this sequence diagram,it is assumed that the FAP holds a SIM and EAP-SIM will be used.

The AAA server formulates an EAP-SIM/Challenge with multiple RANDchallenges, and includes a message authentication code (MAC) whosemaster key is computed based on the associated Kc keys, as well as theNONCE_MT. A new re-authentication identity may be chosen and protected(i.e. encrypted and integrity protected) using EAP-SIM generated keyingmaterial. The AAA Server sends (in Step 11) this RAND, MAC andre-authentication identity to the GANC-SeGW in the EAPRequest/SIM-Challenge message. The GANC-SeGW forwards (in Step 12) theEAP Request/SIM-Challenge message to the FAP.

The FAP runs (in Step 12) N times the GSM A3/A8 algorithm in the SIM,once for each received RAND. This computing gives N SRES and Kc values.The FAP calculates its copy of the network authentication MAC with thenewly derived keying material and checks that it is equal with thereceived MAC. If the MAC is incorrect, the network authentication hasfailed and the FAP cancels the authentication. The FAP continues theauthentication exchange only if the MAC is correct. The FAP calculates anew MAC with the new keying material covering the EAP messageconcatenated to the N SRES responses. If a re-authentication ID wasreceived, then the FAP stores this ID for future authentications.

The FAP 4705 sends (in Step 14) EAP Response/SIM-Challenge includingcalculated MAC to the GANC-SeGW 4715. The GANC-SeGW forwards (in Step15) the EAP Response/SIM-Challenge message to the AAA Server 4720. TheAAA Server verifies (in Step 16) that its copy of the response MAC isequal to the received MAC.

If the comparison in step 16 is successful, then the AAA Server sends(in Step 17) the EAP Success message to the GANC-SeGW. The AAA Serverincludes derived keying material for confidentiality and/or integrityprotection between FAP and GANC-SeGW, in the underlying AAA protocolmessage (i.e. not at EAP level).

The GANC-SeGW informs (in Step 18) the FAP about the successfulauthentication with the EAP Success message. Now the EAP-SIM exchangehas been successfully completed, the IKE signaling can be completed (inStep 19). The Secure Association between FAP and GANC-SeGW has beencompleted and the FAP can continue with the Femtocell discovery orregistration procedure.

2. EAP-AKA Procedure for Authentication

The EAP-AKA authentication mechanism is specified in “ExtensibleAuthentication Protocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA)”, IETF RFC 4187. This section describes how thismechanism is used in Femtocell. FIG. 48 illustrates EAP-AKAauthentication procedure of some embodiments. As shown, the FAP 4805connects to the generic IP access network and obtains (in Step 1) the IPaddress of the Default or the Serving SeGW via DNS query. The DNS server4810 returns (in Step 10) the IP address of the SeGW.

The FAP 4805 initializes the IKEv2 authentication procedure by startingthe IKE_SA_INIT exchange (Steps 3 a-3 c). It indicates the desire to useEAP by leaving out the AUTH payload from message 3, the first message ofthe IKE_AUTH exchange, and the initiator identity is composed compliantwith the Network Access Identifier (NAI) format specified in the IETFRFC 2486 which includes the IMSI and an indication that EAP-AKA shouldbe used.

Next, the GANC-SeGW 4815 sends (in Step 4) an EAP Response/Identitymessage to the AAA server 4820, including the initiator identityincluded in the third IKE message. The leading digit of the NAIindicates that the FAP wishes to use EAP-AKA. The AAA server identifiesthe subscriber as a candidate for authentication with EAP-AKA, based onthe received identity, and verifies that EAP-AKA shall be used based onsubscription information, The AAA server requests (in Step 5) the userprofile and UMTS authentication vector(s) from the HSS/HLR 4825, ifthese are not available in the AAA server.

Optionally, the AAA receives (in Step 6) user subscription and UMTSauthentication vector(s) from the HSS/HLR. The UMTS authenticationvector consists of random part (RAND), an authentication token (AUTN),an expected result part (XRES) and sessions keys for integrity check(IK) and encryption (CK). The AAA server determines the EAP method (SIMor AKA) to be used, according to the user subscription and/or theindication received from the FAP. In this sequence diagram, it isassumed that the FAP holds a USIM and EAP-AKA will be used.

Next, the AAA server 4820 formulates an EAP-Request/AKA Challenge withRAND, AUTN and includes a message authentication code (MAC) whose masterkey is computed based on the associated IK and CK. A newre-authentication identity may be chosen and protected (i.e. encryptedand integrity protected) using EAP-AKA generated keying material. TheAAA Server sends (in Step 7) the RAND, AUTN, MAC and re-authenticationidentity to the GANC-SeGW 4815 in the EAP Request/AKA-Challenge message.

The GANC-SeGW forwards (in Step 8) the EAP Request/AKA-Challenge messageto the FAP. The FAP runs (in Step 9) UMTS algorithm on the USIM. TheUSIM verifies that the AUTN is correct and hereby authenticates thenetwork. If AUTN is incorrect, the FAP rejects the authentication. IfAUTN is correct, the USIM computes RES, IK and CK. The FAP calculates anew MAC with the new keying material (IK and CK) covering the EAPmessage. If a re-authentication ID was received, then the FAP storesthis ID for future authentications.

The FAP then sends (in Step 10) EAP Response/AKA-Challenge includingcalculated RES and MAC to the GANC-SeGW. The GANC-SeGW forwards (in Step11) the EAP Response/AKA-Challenge message to the AAA Server.

The AAA Server verifies (in Step 12) the received MAC and compares XRESto the received RES. If the checks in Step 12 are successful, then theAAA Server sends (in Step 13) the EAP Success message to the GANC-SeGW.The AAA Server includes derived keying material for confidentialityand/or integrity protection between FAP and GANC-SeGW, in the underlyingAAA protocol message (i.e. not at EAP level).

The GANC-SeGW informs (in Step 14) the FAP about the successfulauthentication with the EAP Success message. Now the EAP-SIM exchangehas been successfully completed, the IKE signaling can be completed (inStep 15). The Security Association between FAP and GANC-SeGW has beencompleted and the FAP can continue with the Femtocell discovery orregistration procedure.

3. Fast Re-Authentication

When the authentication process is performed frequently, especially witha large number of connected Femtocell Access Points, performing fastre-authentication can reduce the network load resulting from thisauthentication. The fast re-authentication process allows the AAA serverto authenticate a user based on keys derived from the last fullauthentication process.

The FAP and GANC-SeGW can use a procedure for fast re-authentication inorder to re-authenticate an FAP e.g. when setting up a new SA becausethe IP address of the FAP has changed. Fast re-authentication isprovided by EAP-AKA, and does not make use of the UMTS algorithms. TheFAP may use the re-authentication ID in the IKE_SA_INIT. The decision tomake use of the fast re-authentication procedure is taken by the AAAserver.

The basic elements of these procedures are the following. The FAPinitiates a new SA with a GANC-SeGW that it was previously connected toand uses the re-authentication ID (re-authentication ID received duringthe previous full authentication procedure) in the IKE_SA_INIT exchange.The EAP-AKA procedure is started as a result of these exchanges. The AAAserver and FAP re-authenticate each other based on the keys derived onthe preceding full authentication.

B. Encryption

All control and user plane traffic over the Up interface shall be sentthrough the IPSec tunnel that is established as a result of theauthentication procedure. Encryption shall use the negotiatedcryptographic algorithm, based on core network policy, enforced by theGANC-SeGW.

The FAP and GANC-SeGW set up one Security Association through which alltraffic is sent. A single negotiated ciphering algorithm is applied tothe connection.

1. Establishment of a Security Association

After the authentication procedure, the FAP shall request an IP addresson the network protected by the GANC-SeGW (i.e. the public IP interfaceof the INC). The FAP shall set up one IPSec Security Association (SA)between FAP and GANC-SeGW.

The FAP shall initiate the creation of the SA; i.e. it shall act asinitiator in the Traffic Selector negotiation. The protocol ID field inthe Traffic Selectors (TS) shall be set to zero, indicating that theprotocol ID is not relevant. The IP address range in the TSi shall beset to the address assigned to the FAP (within the network protected bythe GANC-SeGW). The IP address range in the TSr shall be set to0.0.0.0-255.255.255.255. The FAP and GANC-SeGW shall use the IKEv2mechanisms for detection of NAT, NAT traversal and keep-alive.

All control and user plane data over the Up interface between FAP andINC shall be sent through the SA. The ciphering mode is negotiatedduring connection establishment. During setup of the SA, the FAPincludes a list of supported encryption algorithms as part of the IKEsignaling, which include the mandatory and supported optional algorithmsdefined in the IPSec profile, and NULL encryption. The GANC-SeGW selectsone of these algorithms, and signals this to the FAP.

When NULL encryption is applied, both control and user-plane traffic issent unencrypted. This configuration can be selected e.g. when theconnection between the generic IP access network and the GANC is underoperator control. The integrity algorithm is the same as for eitherconfiguration i.e. non-ciphered traffic is still integrity protected.

C. Profile of IKEv2

In some embodiments, profile of IKEv2 for Femtocell system is similar tothe profile defined in TS 43.318 standard.

D. Profile of IPSec ESP

In some embodiments, profile of IPSEC ESP for Femtocell system issimilar to the profile defined in TS 43.318 standard.

E. Security Mode Control

FIG. 49 illustrates the message flow for security mode control in someembodiments. As shown, the CN (VLR/SGSN) 4920 and the UE 4905 perform(in Step 1) mutual authentication using AKA procedures. The CNauthentication is initiated by the CN as a result of the CN processingan initial L3 message from the UE.

Upon successful authentication, the CN sends (in Step 2) RANAP “SecurityMode Command” message to GANC. This message includes the integrity key(IK) key, the ciphering (or encryption) key (CK), the user integrityalgorithm (UIA), and the ciphering (or user encryption) algorithm (UEA)to be used for ciphering.

In some embodiments, the GANC stores the ciphering and integrity keysand the algorithms. The GANC sends (in Step 3) a GA-CSR SECURITY MODECOMMAND with the ciphering and integrity keys and algorithms associatedwith the specific UE IMSI to the FAP 4910. The FAP stores the cipheringand integrity keys and algorithm (in Step 4) for the specific UE. TheFAP should ensure that these keys are not accessible to 3^(rd) partyapplications or any other module on the FAP. Additionally, these keysshould not be stored on any persistent storage. The CK and UEA are usedto protect the air interface between the FAP and the UE by encryptingthe traffic between the FAP and the UE. The IK and the UIA are used toensure the integrity of the messages exchanged between the FAP and theUE over the air interface, for example by determining that the messagesare not changed. In some embodiments, the UIA and the UEA are softwaremethods executed by a processor.

The FAP generates a random number (FRESH) and computes the downlink(i.e., from the FAP to the UE) message authentication code (MAC) usingthe integrity key (IK) and integrity algorithms (MAC-I) and sends (inStep 5) the Security Mode command to the UE 4905 along with the computedmessage authentication code for integrity (MAC-I) and the FRESH. TheFRESH variable represents a random number or nonce as defined in “3GSecurity; Security architecture”, 3GPP TS 33.102 standard, hereinafter“TS 33.102 standard”. The UE computes (in Step 6) the MAC-I locally(expected MAC-I or XMAC-I) and verifies (in Step 6) that the receiveddownlink MAC-I is same. The UE computes XMAC-I on the message receivedby using the indicated UIA, COUNT-I generated from the stored START andthe received FRESH parameter as defined in TS 33.102 standard. Thedownlink integrity check is started from this message onwards. For allsubsequent messages sent from the FAP to the UE (the downlink messages),steps similar to Steps 5 to 6 are used to ensure the integrity of themessages.

Upon successful verification of the MAC, the UE responds back (in step7) with the Security Mode Complete command and also sends the MAC-I forthe uplink (i.e., from the UE to the FAP) message. The FAP computes (inStep 8) XMAC-I for the uplink message and verifies (in Step 8) thereceived MAC-I is same as that of computed XMAC-I. The uplink integritycheck is started from this message onwards. For all subsequent messagessent from the UE to the FAP (the uplink messages), steps similar toSteps 7 to 8 are used to ensure the integrity of the messages.

MAC-I is the sender's computed MAC-I and XMAC-I is the expected MAC-Icomputed by the receiver. As described above, the computation is donefor a given message using the algorithms and other variables which areknown to the sender and receiver only. This prevents a man-in-the-middleattack, as the middle entity will not have the necessary information tocompute MAC-I and hence cannot tamper the message.

Upon successful verification of the uplink MAC, the FAP sends (in Step9) the GA-CSR Security mode complete command to the GANC. The GANCrelays (in Step 10) the Security Mode Complete command to the CN viacorresponding RANAP message.

F. Core Network Authentication

The core network AKA based authentication provides mutual authenticationbetween the user and the network. The AKA procedure is also used togenerate the ciphering keys (encryption and integrity) which in turnprovide confidentiality and integrity protection of signaling and userdata. The basis of mutual authentication mechanism is the master key K(permanent secret with a length of 128 bits) that is shared between theUSIM of the user and home network database. The ciphering key (Ck) andthe integrity key (Ik) are derived from this master key K.

FIG. 50 illustrates the AKA procedure used for mutual authentication insome embodiments. As shown, when the UE 5005 camps on the FemtocellAccess Point 5010, it initiates (in Step 1) a Location Update Request(or Location Updating Request) towards the CN. The INC 5015 forwards) inStep 2) the Location Update request in a RANAP message to the VLR/SGSN5020.

This triggers the authentication procedure in the VLR/SGSN and it sends(in Step 3) an authentication data request MAP message to theAuthentication Center (AuC) in the Home Environment (HE) 5025. The AuCincludes the master keys of the UEs and based on the IMSI, the AuC willgenerate the authentication vectors for the specific UE. The vector listis sent back (in Step 4) to the VLR/SGSN in the authentication dataresponse MAP message.

The VLR/SGSN selects (in Step 5) one authentication vector from the list(only 1 vector is needed for each run of the authentication procedure).The VLR/SGSN sends (in Step 6) user authentication request (AUTREQ)message to the INC. This message also includes two parameters RAND andAUTN (from the selected authentication vector).

The INC 5015 relays (in Step 7) the AUTREQ message to the FAP 5010 in aGA-CSR DL DIRECT TRANSFER message. The FAP forwards (in Step 8) theAUTREQ to the UE over the air interface. The USIM on the UE includes themaster key K and using it with the parameters RAND and AUTN as inputs,the USIM carries out computation resembling generation of authenticationvectors in the AuC. From the generated output, the USIM verifies (inStep 9) if the AUTN was generated by the right AuC.

The USIM computation also generates (in Step 10) a RES which is senttowards the CN in an authentication response message to the CN. The FAPforwards (in Step 11) the Authentication Response to INC. The INC relays(in Step 12) the response along with the RES parameter in a RANAPmessage to the CN.

The VLR/SGSN verifies (in Step 13) compares the UE response RES with theexpected response XRES (which is part of authentication vector). Ifthere is a match, authentication is successful. The CN may then initiate(in Step 14) a Security Mode procedure (as described in the Subsection“Security mode control”, above) to distribute the ciphering keys to theINC.

G. Service Theft in Femtocell

By definition, the FAP has a radio interface (Uu) to communicate withUEs and a network interface (Up) to the mobile network. The FAP relaysmessages between the UE and core network and can eavesdrop and interceptthese messages. The FAP, if compromised, becomes the infamous ‘man’ ofthe man-in-the-middle security exposure.

In normal operation, the macro cell network directs UEs to scan for theFemtocell UTRA Absolute Radio Frequency Channel Number (UARFCN) andscrambling code (SC) so when a UE detects FAP radio coverage, the UE canattempt to camp on the FAP. The FAP {UARFCN, SC} is expected to beconfigured in the macro network RNC's neighbor cell list so that RNC canprovide the UE with this neighbor cell list, thus resulting in the UEperforming the scans of the neighbors cells and eventual cell selectionof a better neighbor for camping. The UE performs a location update,provides its identity, whether IMSI or TMSI, expects to beauthenticated, and then proceeds to camp on the Femtocell for mobileservice. This is exactly what is supposed to happen when the UE visits anetwork authorized FAP.

When the FAP is compromised or is a rogue, then the UE could be exposingitself to theft of service. When the UE provides its identity to theFAP, the FAP can masquerade as the UE to the mobile network. Normally,UE authentication would prevent this kind of identity theft, but beingin the middle of the communication between the core network and the UE,the FAP can relay authentication requests to the victim UE to defeatauthentication.

The UE believes it is being authenticated by the network and providesthe correct authentication response to the FAP. The FAP sends thecorrect response to the core network and the core network now believesthe FAP has been authenticated. In between network initiatedauthentication requests, the FAP can request and receive service fromthe mobile network disguised as the victim UE. For example, callsoriginated by the FAP would now be charged to the victim UE. UMTSsignaling message integrity mechanisms do not help in this case becausethe integrity protection is provided over the air interface between theUE and the FAP.

Since the FAP is in the possession of the end user and communicates withthe GANC over the Internet, it is possible for a compromised or rogueFAP to attempt to circumvent the UMTS security architecture. A rogue FAPis the classical man-in-the-middle attacker between the UE and the CN.Without adequate network security validations and the enforcement ofaccess policies, rogue FAPs can masquerade as a victim UE and use mobilenetwork services using the victim UE's identity. A FAP is categorized inthe following three access control modes: closed access, semi-openaccess, or open access.

In a closed access case, access to complete Femtocell services over agiven FAP is restricted to a closed group of subscribers. In a semi-openaccess case, limited access is provided to all subscribers. A subscriberwho is not part of the closed group is allowed to receive incoming callsand SMS over the semi-open FAP. Additionally, the subscriber is alsoallowed to make emergency calls using the FAP operating in semi-openaccess mode. All other services, such as outgoing calls, are blocked.Finally, in an open access case, all subscribers of a given operator areallowed full service access over a FAP operating in open access mode.The following techniques are used in some embodiments to protect againstUE masquerade and theft of service at a FAP operating in one of abovementioned modes.

1. Closed Access Points

In a closed access FAP, UEs that are members of the FAP's private usergroup cannot be victimized because the FAP and the UEs in the privateuser group are linked by the subscription process. The GANC can enforcenetwork-based service access controls to prevent victim UEs from beingtrapped by a rogue FAP. If the UE is not a member of the private usergroup of the rogue FAP, the GANC will deny service access to the UE.This means the rogue FAP is prevented from stealing service with thevictim UE's identity.

The GANC also strictly binds transactions performed under each UEregistration context to the original authorized UE identity to prevent arogue FAP from piggybacking messages using a victim UE identity throughthe authorized UE context. The strict binding requires the GANC to trackthe identity of each UE even as it is assigned TMSI and P-TMSI for UserIdentity Confidentiality. Prevention of service theft in a closed accessmode is described in detail further below.

2. Semi-Open and Open Access Points

The potential for a rogue FAP to masquerade as a victim UE is onlyavailable on the semi-open and open access points. The victim UEs wouldbe the UEs that the network allows to camp on the rogue FAP but is not amember of the FAP's private user group. For those UEs, the theft ofservice potential is real because the rogue FAP has an incentive tocharge its usage to the victim UE subscription account.

Note, the theft-of-service scenario is only possible while a victim UEis camped on the rogue FAP. The rogue FAP can authenticate to the corenetwork (CN) as the UE and then request services from the CNmasquerading as the UE. So long that the victim UE remains camped at therogue FAP, the FAP can continue to pass authentication requests andcarry on the masquerade.

For semi-open FAPs, by definition, prevents outgoing services to beinitiated by UEs that are not a member of the FAP's private user group.Network-based enforcement of the semi-open access controls can preventrogue FAPs from stealing service by masquerading as a victim UE.However, a rogue FAP can block incoming calls to the victim UE oreavesdrop on the conversation while the victim UE is camped on the rogueFAP. The semi-open FAP scenario is similar to the open FAP scenariodescribed below.

For open FAPs, the GANC by definition cannot place restrictions on theusage of mobile network services for any UE. It is also not possible todetermine on a per call basis whether the call was legitimately made bythe UE or whether the FAP is masquerading as a victim UE. This makesnetwork enforcement of UE access controls ineffective for preventing UEmasquerade. The prevention method must focus on ensuring only genuineand unmodified FAPs are granted open access.

3. Enhanced Security Solution for Open Access Points

Open FAPs can be misused through the following two scenarios: (1)Complete replacement of a genuine FAP with rogue equipment and (2)Modification of the existing software executing on the FAP from anauthorized vendor.

a) Detection of Genuine FAP

The replacement of a genuine FAP with rogue equipment can be preventedusing a technique based on public and private keys. In this solution theFAP is required to provide a Message Authentication Code (MAC), computedfrom the vendor's private key, with the UMA Registration message. TheGANC, using the AAA, can verify the MAC on the UMA Registration messageby comparing the MAC with one computed with the FAP vendor's public key.Only genuine FAPs can provide the correct MAC in the UMA Registrationmessage.

Procedure details are as follows. Each FAP vendor generates aprivate/public key pair. The public key is stored in a FAP database inthe network. When the FAP registers with the GANC, the GANC sends aRegister challenge message by including a RAND number in the challenge.The FAP sends the challenge response and includes the MAC (messageauthentication code) generated using the vendor's private key. The MACis generated using the standard algorithms for SHA1.

The GANC relays the random number and the generated MAC to the AAA viathe S1 interface. The AAA retrieves the public key from the FAP databaseand computes its expected MAC. If the locally computed MAC is the sameas that received over the network, then AAA has verified the FAP isgenuine. If the MAC check in the AAA fails, the registration is rejectedthus preventing access to services using the GANC. Note there is oneprivate key for all FAPs from the same vendor so every FAP has the sameimage. The private key should never be stored in an unencrypted fashion.This detection method must be combined with the following method toprotect the private keys from being extracted from the FAP.

b) Ensuring Unmodified FAPs

The FAP hardware may implement a “software authentication” technique toensure only authentic, authorized software is allowed to execute on theFAP hardware. Some embodiments perform the following softwareauthentication technique. The “bootloader” software, which isresponsible for establishing the initial state of the system, so thatthe proper operating system and application can be loaded, will controlthe download and authorization of the software. The “bootloader”software must be implicitly trusted and therefore needs to be immutable.This requirement can be met, for example, by implementing the bootloadersoftware in ROM or OTP flash.

The software loaded on the FAP is signed using the private key for eachvendor. The bootloader software would be responsible for verification ofthis signature using the public key of the vendor. A failed signaturecheck will prevent the “rogue” software from executing successfully.Note that the public key can be delivered to the bootloader software viasigned certificates or it can be stored directly locally in thebootloader.

The above technique prevents the loading of software onto the FAPhardware by anyone except the vendor. Only the vendor possesses theprivate key necessary to sign the software and pass the “softwareauthentication.”

4. High Level Procedure

FIG. 51 illustrates the high level procedure which can result in theftof service by a rogue FAP. The following description of the Femtocellservice theft procedure assumes the following: (1) the Rogue FAP is aclosed AP i.e. Femtocell service access is limited to a trusted list ofUEs (in this example, only UE-1 associated with identity IMSI-1/TMSI-1is allowed Femtocell service access using the Rogue FAP), (2) closed APhas implied security as part of mutual trust between FAP and theassociated UEs. The close AP behavior is ensured by the network usingservice access control (SAC) at the time of UE registration, (3) victimUE is associated with identity IMSI-2/TMSI-2 and is NOT allowed serviceon this Rogue FAP, and (4) the ‘Rogue’ FAP has been compromised and isattempting to steal services using victim UE identity outside the trustlist. Although FIGS. 51 to 53 illustrate steps related to circuitswitched resources (CSR), a person of ordinary skill in the art would beable to apply the same techniques to packet switched resources (PSR).

As shown in FIG. 51, the authorized UE 5110 establishes (in Step 1 a) aRRC connection with the FAP 5115 on which it camps. The UE 5110 starts(in Step 1 b) a Location Update procedure towards the CN 5130. The FAP5115 will intercept the Location Update request and attempts to registerthe UE 5110 with the associated Serving GANC 5120 over the existingIPSEC tunnel. The FAP 5115 may request (in Step 1 c) and receive (inStep 1 d) the IMSI of the UE 5110 if the Location Update is done usingthe TMSI, since the IMSI is required for the initial registration of theUE.

Next, the FAP 5115 attempts to register the UE 5110 on the GANC 5120using the UE specific TCP connection by transmitting (in Step 2) theGA-RC REGISTER REQUEST. The message includes: (1) Registration Type:Indicates that the registering device is a UE, (2) Generic IP accessnetwork attachment point information: AP-ID, (3) UE Identity: UE-IMSI,and (4) FAP identity: FAP-IMSI. The GANC 5120 will, via AAA server 5125,authorize (in Steps 2 a-2 c) the UE 5110 using the information providedin the REGISTER REQUEST. The authorization logic on the AAA server 5125would also check to see if the UE 5110 is allowed Femtocell access usingthe specific FAP 5115.

When the GANC 5115 accepts the registration attempt, the GANC responds(in Step 3) with a GA-RC REGISTER ACCEPT. The FAP 5115 encapsulates (inStep 4) the Location Update NAS PDU within a GA-CSR UL DIRECT TRANSFERmessage that is forwarded to the GANC 5120 via the existing TCPconnection.

The GANC 5120 establishes a SCCP connection to the CN and forwards (inStep 5) the Location Update request NAS PDU to the CN using the RANAPInitial UE Message. Subsequent NAS messages between the UE and corenetwork will be sent between GANC and CN using the RANAP Direct Transfermessage. The CN 5130 authenticates (in Step 6) the UE 5110 usingstandard UTRAN authentication procedures. The CN 5130 also initiates(also in Step 6) the standard Security Mode Control procedure asdescribed in TS 33.102 standard, which results in distribution of thesecurity keys {CK, IK} for the specific UE to the FAP via the GANC.

Next, the CN 5130 indicates (in Step 7) that it has received thelocation update and it will accept the location update using theLocation Update Accept message to the GANC 5120. The GANC 5120 forwardsthis message to the FAP 5115 in the GA-CSR DL DIRECT TRANSFER. Next, theFAP relays (in Step 9) the Location Update Accept over the air interfaceto the UE 5120.

At this point, a session authorized for the specific UE-1 using itscredentials IMSI-1 is established (in Step 10) between the FAP 5115 andGANC 5120. Next, a victim UE 5105, in the vicinity of the rogue FAP5115, upon discovering the FAP 5115 over the air interface, will attemptto camp on the rogue FAP 5115 based on its internal cell selectionlogic. This will trigger the UE 5105 to establish (in Step 11 a) an RRCconnection with the Rogue FAP 5115. The UE will then start (in Step 11b) a Location Update procedure towards the CN 5130. The FAP 5115 willintercept the Location Update request. The FAP will then request (inStep 11 c) and receive (in Step 11 d) the IMSI of the victim UE 5105 ifthe Location Update is done using the TMSI.

The rogue FAP instead of attempting a registration of the victim UE 5105with the GANC 5120, will re-use the existing authorized session of UE-15110 (as described in step 10) to transfer messages to the CN 5130 viaGANC 5120. It is important to note that if the registration for thevictim UE was attempted by the rogue FAP using the victim UE credentials(i.e. IMSI-2), the network based SAC would have rejected theregistration request since the victim UE-2 5105 is not authorized to useFemtocell service over the specific rogue FAP 5115.

The FAP 5115 encapsulates the Location Update NAS PDU within a GA-CSR ULDIRECT TRANSFER message that is forwarded (in Step 13) to the GANC 5120via the existing TCP connection of UE-1 5110. The GANC 5120 establishesa SCCP connection to the CN 5130 and forwards (in Step 14) the LocationUpdate request NAS PDU to the CN 5130 using the RANAP Initial UEMessage. Subsequent NAS messages between the UE 5105 and core network5130 will be sent between GANC 5120 and CN 5130 using the RANAP DirectTransfer message.

Next, the CN 5130 authenticates (in Step 15) the victim UE-2 usingstandard UTRAN authentication procedures. The authentication messagesare relayed transparently to the UE 5105 by the GANC 5120 and FAP 5115.The CN 5130 also initiates (in Step 15) the standard Security ModeControl procedure as described in TS 33.102 standard, which results indistribution of the security keys {CK, IK} for the victim UE to the FAPvia the GANC.

Upon completion of the authentication, the CN 5130 indicates (in Step16) it has received the location update and it will accept the locationupdate using the Location Update Accept message to the GANC 5120. TheGANC 5120 forwards (in Step 17) this message to the FAP 5115 in theGA-CSR DL DIRECT TRANSFER. The FAP 5115 relays (in Step 17) the LocationUpdate Accept over the air interface to the victim UE.

The CN 5130 now thinks that the victim UE 5105 has been authenticatedvia the FAP 5115 and the GANC 5120 and will accept service requests fromthe victim UE 5105 without additional authentication for a specific timewindow. This time window, during which no addition authentication isperformed for a given subscriber, is typically controlled by the CN 5130based on specific implementation. The FAP 5115 takes advantage of thiswindow and can now initiate service requests using the victim UE 5105credentials and identity e.g. the FAP 5115 can now originate a MobileOriginated (MO) call using IMSI-2 as the subscriber identity resultingin fraudulent charge to the victim UE's subscription. It is important tonote that even if the CN 5130 decides to authenticate every servicerequest from a given subscriber (such as MO), the FAP 5115 can relay theauthentication messages to the victim UE 5105 and accomplish successfulauthentication to the CN 5130.

H. Mechanisms for Preventing Service Theft in Femtocell

In this sub-section, a GANC is disclosed that protects the mobilenetwork from the kind of man-in-the-middle theft scenario describedabove. The theft-of-service risk is different for different classes ofUEs. For UEs that are affiliated with the FAP through a linkedsubscription account such as a family plan, the theft-of-service riskcan be mitigated through the design of the plan pricing to remove anyincentive to mislead the network. The FAP would only be stealing servicefrom its own account.

For UEs that are not affiliated with the FAP, the theft of servicepotential is real because the rogue FAP now has an incentive to chargeits usage to a victim UE account. The GANC has the responsibility toprevent non-affiliated UEs from being captured by the FAP. The GANC doesthis by restricting each FAP to serve a defined list of affiliated UEs.The disclosed GANC AAA-based service access controls provides thedecision logic to enable this UE restriction. Every UE access isindividually authorized through the AAA during the UE UMA registration.The AAA only authorizes UE access after validating that the UE and theFAP are affiliated and the UE access originated from the same IPaddress, through the same IPSec tunnel as the FAP. The GANC enforces theAAA authorization decision by accepting or denying the UMA registrationrequest for the UE.

In addition, all subsequent communications from the UE are validated bythe GANC to prevent rogue FAPs from attempting to insert control planemessages for the victim UE into previously authorized registrationcontexts. The GANC monitors the allocation of TMSI and P-TMSI to the UEso it can associate the UE with any of the UE's identities: IMSI, TMSI,and P-TMSI. This allows the GANC to enforce the UE-FAP affiliation oncommunication between the UE and the core network no matter whether thecontrol plane messages are addressed with the UE IMSI, TMSI, or P-TMSI.The following two sub-sections describe the high level procedures withtwo different approaches which prevent attempted service theft by arogue FAP

1. Service Theft Prevention—Approach 1

FIG. 52 illustrates the Femtocell service theft prevention approach ofsome embodiments. Steps 1-7 are the same as Step 1-7 described inrelation with FIG. 51 above. The GANC 5220 monitors (in Step 8)allocation of new temporary identity to the UE 5210 by the CN 5230, i.e.TMSI for CS services and P-TMSI for PS services, and creates anassociation between the TMSI or P-TMSI and session identity for thespecific UE. The GANC will utilize this information to perform securitychecks on session identity for subsequent NAS layers messagesoriginating on the UE specific session.

The GANC 5220 forwards (in Step 9) the Location Update informationreceived from the CN 5230 to the FAP 5215 using a GA-CSR DL DIRECTTRANSFER message. The FAP 5215 relays (In Step 10) the Location UpdateAccept over the air interface to the UE 5210.

At this point, a session authorized for the specific UE-1 using itscredentials IMSI-1 is established (in Step 11) between the FAP 5215 andGANC 5220. Next, a victim UE 5205, in the vicinity of the rogue FAP5215, upon discovering the FAP 5215 over the air interface, attempts tocamp on the rogue FAP based on its internal cell selection logic. Thiswill trigger the UE 5205 to establish (in Step 12 a) a RRC connectionwith the Rogue FAP. The UE 5205 then starts (in Step 12 b) a LocationUpdate procedure towards the CN 5230. The FAP 5215 intercepts theLocation Update request. The FAP will then request (in Step 12 c) andreceives (in Step 12 d) the IMSI of the victim UE 5205 if the LocationUpdate is done using the TMSI.

The rogue FAP 5215 instead of attempting a registration of the victim UE5205 with the GANC 5220, re-uses (in Step 13) the existing authorizedsession of UE-1 5210 (as described in Step 11 above) to transfermessages to the CN 5230 via GANC 5220. It is important to note that ifthe registration for the victim UE 5205 was attempted by the rogue FAP5215 using the victim UE 5205 credentials (i.e. IMSI-2), the networkbased SAC would have rejected the registration request since the victimUE-2 5205 is not authorized Femtocell service over the specific rogueFAP 5215.

Next, the FAP 5215 encapsulates the Location Update NAS PDU within aGA-CSR UL DIRECT TRANSFER message that is forwarded (in Step 14) to theGANC 5220 via the existing TCP connection of UE-1 5210. The GANC 5220performs (in Step 15) a security check on the session identity. Sincethe identity carried in the Location Update messages i.e. IMSI-2 doesnot match any of the known identities for the session (IMSI-1 which isthe identity used for registration and authorization or the TMSI learntby the GANC 5220 as described in Step 8 above), the GANC 5220 is able todetect the attempted service theft.

The GANC prevents the attempted service theft by deregistering thesession for UE-1 5210. The GANC 5220 sends (in Step 16) a deregistrationmessage to the FAP 5215 on the specific session (the authorized sessionfor UE-1) on which the service theft was being attempted.

2. Service Theft Prevention—Approach 2

FIG. 53 illustrates the Femtocell service theft prevention in someembodiments. Steps 1-15 are the same as Step 1-15 described in relationwith FIG. 52 above. Since the identity carried in the NAS PDU does notmatch any of the known identities for that session, GANC 5320 replacesthe identity in the Location Update message with the original authorizedidentity for the specific session i.e., IMSI-2 is replace with IMSI-1 inthe NAS PDU. The GANC establishes a SCCP connection to the CN 5330 andforwards (in Step 16) the modified Location Update request NAS PDU tothe CN 5330 using the RANAP Initial UE message. The CN 5330 receives aservice request with UE-1's identity in the request and will associatethe request with UE-1 5310 subscriber data including billing, etc.

XIII. FEMTOCELL SERVICE ACCESS CONTROL

Femtocell service access control (SAC) and accounting services are basedon the S1 interface between the INC and one or more AAA servers. The S1interface functions are defined in detail in the above mentioned U.S.application Ser. No. 11/349,025.

The objective of Femtocell service access control is to provideoperators with the tools to properly implement their Femtocell serviceplans based on real-time information from the subscriber and nonreal-time information provisioned within the operator's IT systems andservice databases. Using service policies, the operator can implement arange of creative services and controls to be applied on a perindividual subscriber basis, which results in the acceptance orrejection of any discrete Femtocell session registration request.Primarily, service policies are used to identify whether a subscriber'scurrent request for access meets the conditions of the service plan towhich they are subscribed.

In some embodiments, Femtocell SAC encompasses the discovery,registration and redirection functions as well as enhanced serviceaccess control functions, such as restricting Femtocell service accessbased on the reported FAP MAC address or neighboring macro network UMTScell information.

A local SAC may be performed by the FAP for performance reasons(example: FAP may use local SAC for faster rejection of UEs which arenot allowed access to either Femtocell services or not allowed access toFemtocell services via the specific FAP).

Key elements of the service access control design approach are asfollows:

-   -   1) There are two service access control configuration options:        -   a) Basic service access control: The S1 (INC-AAA) interface            is not deployed and a limited set of service access control            capabilities is provided by the INC.            -   i) The INC is responsible for the Femtocell discovery,                registration and redirection functions.            -   ii) The UMTS-to-Femtocell mapping logic and data is in                the INC; i.e., this is used to support the discovery,                registration and redirection functions and to assign                service areas to specific FAPS.            -   iii) There is no subscriber or FAP-specific service                access control.        -   b) Enhanced service access control: The S1 interface is            deployed and the AAA provides expanded service access            control features, including custom features per service            provider requirements.            -   i) The UMA discovery, registration and redirection                functions remain on the INC.            -   ii) The UMTS-to-Femtocell mapping logic and data remains                in the INC.            -   iii) The AAA supports interfaces to external database                servers; e.g., via LDAPv3.            -   iv) The details of these enhanced service access control                functions are defined in the above mentioned U.S.                application Ser. No. 11/349,025.    -   2) Enablement of the enhanced service access control support        functions (i.e., the service access control functions of the S1        interface) is an INC configuration option; if enabled, the INC        forwards attributes received in the discovery and registration        requests to the AAA using RADIUS. This allows the AAA to (for        example):        -   a) Determine when UE registration attempts should be allowed            or rejected (e.g., limiting service to a single FAP)        -   b) Retrieve FAP location information from an external            database and send the information to the INC.        -   c) Provide a billing rate indicator to the INC that is            incorporated in the UMTS-to-Femtocell SAI mapping process.    -   d) Indicate that hand-in, hand-out, or both are enabled or        disabled for the subscriber.

A. UMTS-to-Femtocell Mapping

The UMTS-to-Femtocell mapping processes include the following:

-   -   1) UMTS-INC Mapping (or “INC Selection”) serves the following        functions:        -   a) It allows an INC functioning as a “provisioning INC” to            direct a mobile station to its designated “default INC”.        -   b) It allows an INC functioning as a “default INC” to direct            a mobile station to an appropriate “serving INC” (e.g., in            case the FAP is outside its normal default INC coverage            area).        -   c) It allows the INC to determine if the UMTS coverage area            is Femtocell-restricted and, if so, to deny service.    -   2) UMTS-Femtocell Service Area Mapping (or “Femtocell Service        Area Selection”) serves the following functions:        -   a) It allows an INC functioning as a “default or serving            INC” to assign the Femtocell service area that shall be            associated with the FAP registration (and all the UEs camped            on that specific FAP). The service area can then be utilized            for emergency call routing as described in the “Service area            based routing” Subsection under the “EMERGENCY SERVICES”            Section, above.

B. Service Access Control (SAC) Examples

The following example service access control are described in thissection: (1) new FAP connects to GAN Femtocell network, (2) FAP connectsto GAN Femtocell network (redirected connection), (3) FAP attempts toconnect in a restricted UMTS coverage area, (4) authorized UE roves intoan authorized FAP for Femtocell service, and (5) unauthorized UE rovesinto an authorized FAP for Femtocell service.

1. New FAP Connects to GAN Femtocell Network

FIG. 54 illustrates SAC for new FAP connecting to Femtocell network insome embodiments. As shown, if the FAP 5405 has a provisioned or derivedFQDN of the Provisioning SeGW, it performs (in Step 1) a DNS query (viathe generic IP access network interface) to resolve the FQDN to an IPaddress. If the FAP has a provisioned IP address for the ProvisioningSeGW, the DNS step is omitted.

The DNS Server 5410 returns (in Step 2) a response including the IPAddress of the Provisioning SeGW 5415. The FAP 5405 establishes (in Step15) a secure tunnel to the Provisioning SeGW 5415 using IKEv2 andEAP-AKA or EAP-SIM.

If the FAP has a provisioned or derived FQDN of the Provisioning INC, itperforms (in Step 4) a DNS query (via the secure tunnel) to resolve theFQDN to an IP address. If the FAP has a provisioned IP address for theProvisioning INC, the DNS step (step 4) will be omitted. The DNS Server5420 returns (in Step 5) a response including the IP Address of theProvisioning INC.

Next, the FAP 5405 sets up (in Step 6) a TCP connection to awell-defined port on the Provisioning INC 5425. The FAP 5405 thenqueries (in Step 7) the Provisioning INC for the Default INC, usingGA-RC DISCOVERY REQUEST. The message includes Cell Info and FAPIdentity. For Cell Info, if the FAP detects macro network coverage, thenit provides the detected UTRAN cell ID and the UTRAN LAI. If the FAPdoes not detect macro network coverage it provides the last LAI wherethe FAP successfully registered, along with an indicator stating whichone it is. For FAP Identity, the message includes IMSI.

The INC 5425 sends (in Step 8) a RADIUS Access-Request message to theAAA server 5435, including attributes derived from GA-CSR DISCOVERYREQUEST message. The AAA server 5435 queries (in Step 9) the Femtocellsubscriber database 5440 for a record matching the IMSI of the FAP. Thesubscriber record is returned (in Step 9) to the AAA server. The AAAserver verifies that FAP IMSI is authorized and FAP is allowed (based onAP-ID i.e., MAC address of the FAP).

AAA server returns (in Step 10) selected Femtocell location informationbased on AP-ID and IMSI to the INC 5425 using the Access Accept message.The INC 5425 determines (in Step 11) the default security gateway andINC (e.g., INC #2 5430) using the UMTS-Femtocell mapping function (seeUMTS-to-Femtocell Mapping Section, above). This is done so the FAP 5405is directed to a “local” Default INC in the HPLMN to optimize networkperformance.

The Provisioning INC 5425 returns (in Step 12) the default INCinformation in the GA-RC DISCOVERY ACCEPT message. The DISCOVERY ACCEPTmessage also indicates whether the INC and SeGW address provided shallor shall not be stored by the FAP. The FAP releases (in Step 13) the TCPconnection and IPSec tunnel and proceeds to register on INC #2.

The FAP performs (in Step 14) a private DNS query using the assignedDefault INC FQDN. The private DNS server 5420 returns (in Step 15) theIP address of INC #2 5430. The FAP establishes (in Step 16) a TCPconnection to INC #2 5430. The FAP sends (in Step 17) a GA-RC REGISTERREQUEST message to the INC.

The INC sends (in Step 18) a RADIUS Access-Request message to the AAAserver, including attributes derived from GA-RC REGISTER REQUESTmessage. The AAA server queries (in Step 19) the Femtocell subscriberdatabase for a record matching the FAP IMSI. The subscriber record isreturned (in Step 19) to the AAA server. The AAA server verifies thatIMSI is authorized and FAP is allowed (based on AP-ID).

Next, the AAA server returns (in Step 20) selected Femtocell serviceattributes to the INC. The INC determines (in Step 21) that it is thecorrect serving INC for the mobile current location using theUMTS-Femtocell mapping function. It also determines (in Step 21) theFemtocell service area to associate with the FAP using theUMTS-Femtocell mapping functions. The INC returns (in Step 22) a GA-RCREGISTER ACCEPT message to the MS

2. FAP Connects to GAN Femtocell Network (Redirected Connection)

FIG. 55 illustrates SAC for the FAP getting redirected in Femtocellnetwork in some embodiments. Steps 1 to 10 are the same steps asdescribed in the “New FAP connects to GAN Femtocell network” Subsection,above. Next, the INC 5525 uses the UMTS-Femtocell mapping function todetermine (in Step 11) that the FAP 5505 should be served by anotherINC.

The INC 5525 sends (in Step 12) the new serving SeGW and INC FQDNs tothe FAP 5505 in the GA-RC REGISTER REDIRECT message. The FAP releases(In Step 13) the TCP connection and IPSec tunnel and proceeds toregister with the designated INC.

3. FAP Attempts to Connect in a Restricted UMTS Coverage Area

FIG. 56 illustrates the SAC for FAP registering in restricted UMTScoverage area in some embodiments. As shown, Steps 1 to 10 are the samesteps as described in the “New FAP connects to GAN Femtocell network”Subsection, above. Next, the INC 5625 uses the UMTS-Femtocell mappingfunction to determine (in Step 11) that the FAP 5605 is in an UMTS areathat is Femtocell restricted (i.e., Femtocell access is not allowed inthe area).

The INC sends (in Step 12) a GA-RC REGISTER REJECT message to the FAP,including reject cause “Location not allowed”. The FAP releases (in Step13) the TCP connection and IPSec tunnel and does not attempt to registeragain from the same UMTS coverage area until powered-off.

4. Authorized UE Roves into an Authorized FAP for Femtocell Service

The sequence of events is same as described in UE Registration Section,above.

5. Unauthorized UE Roves into an Authorized FAP for Femtocell Service

An unauthorized UE (unauthorized for Femtocell service over the specificFAP), upon camping on the FAP (via its internal cell selectionmechanism), will initiate a NAS layer Location Update procedure towardsthe CN via the FAP (The LU is triggered since the FAP broadcasts adistinct LAI than its neighboring macro cells and other neighboringFemtocells). The FAP will intercept the Location Update message andattempt to register the UE with the INC as described below. FIG. 57illustrates the SAC for Unauthorized UE accessing authorized FAP in someembodiments.

As shown, the UE 5705 establishes (in Step 1 a) a RRC connection withthe FAP on which it camps. The UE starts (in Step 1 b) a Location Updateprocedure towards the CN. The FAP 5710 will intercept the LocationUpdate request and attempts to register the UE with the associatedServing INC over the existing IPSec tunnel. Optionally, the FAP mayrequest (in Step 1 c) the IMSI of the UE if the Location Update is doneusing the TMSI, since the initial registration for the UE must be doneusing the permanent identity i.e. the IMSI of the UE.

The FAP sets up a separate TCP connection (for each UE) to a destinationTCP port on the INC 5715. The INC destination TCP port is the same asthat used for FAP registration. The FAP attempts to register the UE onthe INC by transmitting (in Step 2) the GA-RC REGISTER REQUEST. Themessage includes (1) Registration Type which indicates that theregistering device is a UE, (2) the UE Identity which is UE-IMSI, and(3) the FAP identity which is FAP-IMSI.

Optionally, if the INC has been configured for Service Access Control(SAC) over S1 interface, the INC will (in Step 3), via AAA server 5420,authorize the UE 5405 using the information provided in the REGISTERREQUEST. The authorization logic on the AAA server also checks (in Step4) to see if the UE is allowed Femtocell access using the specific FAP.The AAA SAC logic indicates that the registering UE is not authorized toaccess Femtocell service over the specific FAP.

Next, the AAA 5720 sends (in Step 5) Access Reject (with reject causeequivalent to “UE not allowed on FAP”) to the INC 5715. The INC maps (inStep 6) the Access Reject to a GA-RC REGISTER REJECT message to the FAPindicating the reject cause.

The FAP 5710 in turn sends (in Step 7) a Location Updating Reject to theUE 5705 with cause of “Location Area Not Allowed”. This will prevent theUE from attempting to camp on the specific FAP again. While someembodiments use “Location Area Not Allowed” as a mechanism for rejectingunauthorized UEs, other embodiments may use other appropriate UErejection mechanisms.

XIV. COMPUTER SYSTEM

FIG. 58 conceptually illustrates a computer system with which someembodiments of the invention are implemented. The computer system 5800includes a bus 5805, a processor 5810, a system memory 5815, a read-onlymemory 5820, a permanent storage device 5825, input devices 5830, andoutput devices 5835.

The bus 5805 collectively represents all system, peripheral, and chipsetbuses that support communication among internal devices of the computersystem 5800. For instance, the bus 5805 communicatively connects theprocessor 5810 with the read-only memory 5820, the system memory 5815,and the permanent storage device 5825.

From these various memory units, the processor 5810 retrievesinstructions to execute and data to process in order to execute theprocesses of the invention. In some embodiments the processor comprisesa Field Programmable Gate Array (FPGA), an ASIC, or various otherelectronic components for executing instructions. The read-only-memory(ROM) 5820 stores static data and instructions that are needed by theprocessor 5810 and other modules of the computer system. The permanentstorage device 5825, on the other hand, is a read-and-write memorydevice. This device is a non-volatile memory unit that storesinstruction and data even when the computer system 5800 is off. Someembodiments of the invention use a mass-storage device (such as amagnetic or optical disk and its corresponding disk drive) as thepermanent storage device 5825. Some embodiments use one or moreremovable storage devices (flash memory card or memory stick) as thepermanent storage device.

Like the permanent storage device 5825, the system memory 5815 is aread-and-write memory device. However, unlike storage device 5825, thesystem memory is a volatile read-and-write memory, such as a randomaccess memory. The system memory stores some of the instructions anddata that the processor needs at runtime.

Instructions and/or data needed to perform processes of some embodimentsare stored in the system memory 5815, the permanent storage device 5825,the read-only memory 5820, or any combination of the three. For example,the various memory units include instructions for processing multimediaitems in accordance with some embodiments. From these various memoryunits, the processor 5810 retrieves instructions to execute and data toprocess in order to execute the processes of some embodiments.

The bus 5805 also connects to the input and output devices 5830 and5835. The input devices enable the user to communicate information andselect commands to the computer system. The input devices 5830 includealphanumeric keyboards and cursor-controllers. The output devices 5835display images generated by the computer system. The output devicesinclude printers and display devices, such as cathode ray tubes (CRT) orliquid crystal displays (LCD). Finally, as shown in FIG. 58, bus 5805also couples computer 5800 to a network 5865 through a network adapter(not shown). In this manner, the computer can be a part of a network ofcomputers (such as a local area network (“LAN”), a wide area network(“WAN”), or an Intranet) or a network of networks (such as theInternet).

It should be recognized by one of ordinary skill in the art that any orall of the components of computer system 5800 may be used in conjunctionwith the invention. For instance, some or all components of the computersystem described with regards to FIG. 58 comprise some embodiments ofthe UE, FAP, GANC, and GGSN described above. Moreover, one of ordinaryskill in the art will appreciate that any other system configuration mayalso be used in conjunction with the invention or components of theinvention.

XV. DEFINITIONS AND ABBREVIATIONS

The following is a list of definitions and abbreviations used:

-   AAA Authentication, Authorization, and Accounting-   ACL Access Control List-   AES Advanced Encryption Standard-   AH Authentication Header (IPSec)-   AKA Authentication and Key Agreement-   ALI Automatic Location Identification-   AMS access Point Management System-   ANI Automatic Number Identification-   AP Access Point-   APN Access Point Name-   ATM Asynchronous Transfer Mode-   AuC Authentication Center-   CBC Cell Broadcast Center-   CBC Cipher Block Chaining-   CC Call Control-   CDR Call Detail Records-   CMDA Code Division Multiple Access-   CGI Cell Global Identification-   CgPN Calling Party Number-   CLIP Calling Line Presentation-   CK Cipher Key-   CM Connection Management-   CM-sub Connection Management sublayer-   CN Core Network-   CPE Customer Premises Equipment-   CRC Cyclic Redundancy Code-   CRDB Coordinate Routing Database-   CS Circuit Switched-   CTM Cellular Text telephone Modem, as specified in 3GPP 26.226-   DL Downlink-   DNS Domain Name System-   EAP Extensible Authentication protocol-   EAPOL EAP over LANs-   ECB Electronic Code Book (AES Mode)-   ELID Emergency Location Information Delivery-   E-OTD Enhanced Observed Time Difference-   ESN Emergency Services Number-   ESP Emergency Services Protocol or Encapsulating Security Payload    (IPSec)-   ESRD Emergency Services Routing Digits-   ESRK Emergency Services Routing Key-   ETSI European Telecommunications Standards Institute-   FCAPS Fault, Configuration, Accounting, Performance, and Security    management-   FAP Femtocell Access Point-   FCC US Federal Communications Commission-   FQDN Fully Qualified Domain Name-   GA-CSR Generic Access-Circuit Switched Resources-   GAN Generic Access Network-   GANC GAN Network Controller-   GA-PSR Generic Access-Packet Switched Resources-   GA-RC Generic Access-Resource Control-   GDP Generic Digits Parameter-   GERAN GSM EDGE Radio Access Network-   GGSN Gateway GPRS Support Node-   GMLC Gateway Mobile Location Center-   GMM/SM GPRS Mobility Management and Session Management-   GMSC Gateway MSC-   GPRS General Packet Radio Service-   GPS Global Positioning System-   GMM-sub GPRS Mobility Management sublayer-   GRR-sub GPRS Radio Resource sublayer in GSM-   GSM Global System for Mobile communications-   GSN GPRS Support Node-   GTP GPRS Tunnelling Protocol-   GTT GSM Global Text Telephony or SS7 Global Title Translation-   HLR Home Location Register-   HMAC Hashed Message Authentication Code-   HPLMN Home PLMN-   IAM Initial Address Message-   ICMP Internet Control Message Protocol-   IETF Internet Engineering Task Force-   IK Integrity Key-   IKEv2 Internet Key Exchange Version 2-   IMEI International Mobile station Equipment Identity-   IMSI International Mobile Subscriber Identity-   INC IP Network Controller-   IP Internet Protocol-   IPSec IP Security-   IPv4 Internet Protocol version 4-   IPv6 Internet Protocol version 6-   ISDN Integrated Services Digital Network-   ISP Internet Service Provider-   ISUP ISDN User Part-   Iu Interface UTRAN-   IV Initialization Vector-   LA Location Area-   LAC Location Area Code-   LAI Location Area Identity-   LAU Location Area Update-   LU Location Update-   LCS Location Service-   LEAP Lightweight EAP (same as EAP-Cisco)-   LLC Logical Link Control-   LLC-sub Logical Link Control sublayer-   LMSI Local Mobile Subscriber Identity-   LSB Least Significant Bit-   LSP Location Services Protocol-   M Mandatory-   M3UA MTP3 User Adaptation Layer-   MAC Media Access Control or Message Authentication Code (same as    MIC)-   MAC Address Media Access Control Address-   MAC-I Message Authentication Code for Integrity-   MAP Mobile Application Part-   MDN Mobile Directory Number-   ME Mobile Equipment-   MIC Message Integrity Check (same as Message Authentication Code)-   MG or MGW Media Gateway-   MM Mobility Management-   MM-sub Mobility Management sublayer-   MPC Mobile Positioning Center-   MS Mobile Station-   MSB Most Significant Bit-   MSC Mobile Switching Center-   MSISDN Mobile Station International ISDN Number-   MSRN Mobile Station Roaming Number-   MTP1/2/3 Message Transfer Part Layer 1/2/3-   NAS Non Access Stratum-   NCAS Non Call Associated Signaling-   NDC National Destination Code-   NS Network Service-   NSAPI Network layer Service Indoor Base Station Identifier-   NSS Network SubSystem-   O Optional-   OCB Offset Code Book (AES Mode)-   OTP One Time Programmable-   pANI pseudo-ANI: Either the ESRD or ESRK-   PCS Personal Communications Services-   PCU Packet Control Unit-   PDCH Packet Data CHannel-   PDE Position Determining Entity-   PDN Packet Data Network-   PDP Packet Data Protocol, e.g., IP or X.25-   PDU Protocol Data Unit-   PEAP Protected EAP-   PKI Public Key Infrastructure-   PLMN Public Land Mobile Network-   POI Point of Interface-   PPF Paging Proceed Flag-   PPP Point-to-Point Protocol-   PSAP Public Safety Answering Point-   PSTN Public Switched Telephone Network-   PTM Point To Multipoint-   P-TMSI Packet TMSI-   PTP Point To Point-   PVC Permanent Virtual Circuit-   QoS Quality of Service-   R Required-   RA Routing Area-   RAB RANAP Assignment Request-   RAC Routing Area Code-   RADIUS Remote Authentication Dial-In User Service-   RAI Routing Area Identity-   RAN Radio Access Network-   RANAP Radio Access Network Application Part-   RFC Request for Comment (IETF Standard)-   RLC Radio Link Control-   RNC Radio Network Controller-   RR-sub Radio Resource Management sublayer-   RSN Robust Security Network-   RTCP Real Time Control Protocol-   RTP Real Time Protocol-   SAC Service Access Control-   SAC Service Area Code SC Scrambling Code-   SCCP Signaling Connection Control Part-   SDCCH Standalone Dedicated Control Channel-   SDU Service Data Unit-   SeGW GANC Security Gateway-   SGSN Serving GPRS Support Node-   SK Service Key-   SIM Subscriber Identity Module-   SM Session Management-   SMLC Serving Mobile Location Center-   SMS Short Message Service-   SM-AL Short Message Application Layer-   SM-TL Short Message Transfer Layer-   SM-RL Short Message Relay Layer-   SM-RP Short Message Relay Protocol-   SMR Short Message Relay (entity)-   SM-CP Short Message Control Protocol-   SMC Short Message Control (entity)-   SM-SC Short Message Service Centre-   SMS-GMSC Short Message Service Gateway MSC-   SMS-IWMSC Short Message Service Interworking MSC-   SNDCP SubNetwork Dependent Convergence Protocol-   SN-PDU SNDCP PDU-   S/R Selective Router-   SS Supplementary Service-   SSID Service Set Identifier (also known as “Network Name”)-   SSL Secure Socket Layer-   STA Station (802.11 client)-   TA Timing Advance-   TCAP Transaction Capabilities Application Part-   TCP Transmission Control Protocol-   TDOA Time Difference of Arrival-   TEID Terminal Endpoint Identifier-   TID Tunnel Identifier-   TKIP Temporal Key Integrity Protocol-   TLLI Temporary Logical Link Identity-   TLS Transport Layer Security-   TMSI Temporary Mobile Subscriber Identity-   TOA Time of Arrival-   TRAU Transcoder and Rate Adaptation Unit-   TTY Text telephone or teletypewriter-   UARFCN UMTS Absolute Radio Frequency Channel Number-   UDP User Datagram Protocol-   UE User Equipment-   UL Uplink-   UMA Unlicensed Mobile Access-   UMTS Universal Mobile Telecommunication System-   USIM UMTS Subscriber Identity Module/Universal Subscriber Identity    Module-   USSD Unstructured Supplementary Service Data-   UTC Coordinated Universal Time-   UTRAN UMTS Terrestrial Radio Access Network-   VLR Visited Location Register-   VMSC Visited MSC-   VPLMN Visited Public Land Mobile Network-   VPN Virtual Private Network-   W-CDMA Wideband Code Division Multiple Access-   WEP Wired Equivalent Privacy-   WGS-84 World Geodetic System 1984-   WPA Wi-Fi Protected Access-   WZ1 World Zone 1

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the invention.However, it will be apparent to one skilled in the art that specificdetails are not required in order to practice the invention. Thus, theforegoing descriptions of specific embodiments of the invention arepresented for purposes of illustration and description. They are notintended to be exhaustive or to limit the invention to the precise formsdisclosed; obviously, many modifications and variations are possible inview of the above teachings. The embodiments were chosen and describedin order to best explain the principles of the invention and itspractical applications, they thereby enable others skilled in the art tobest utilize the invention and various embodiments with variousmodifications as are suited to the particular use contemplated.Moreover, while the invention has been described with reference tonumerous specific details, one of ordinary skill in the art willrecognize that the invention can be embodied in other specific formswithout departing from the spirit of the invention.

In some examples and diagrams, two components may be described or shownas connected to each other. The connection may be a direct wireconnection or the two components may be communicatively coupled to eachother through other components or through wireless or broadband links.Thus, one of ordinary skill in the art would understand that theinvention is not to be limited by the foregoing illustrative details,but rather is to be defined by the appended claims.

1-20. (canceled)
 21. A method of authorizing a Femtocell access point(FAP) of a first communication system, the FAP is for communicativelycoupling a user equipment with a second communication network, themethod comprising: a) receiving a request for registering the FAP withthe first communication system, the request comprising a set ofidentifications of the FAP; b) based on said information, determiningwhether the FAP is authorized to use services of the first communicationnetwork; and c) registering the FAP with the first communication networkwhen the FAP is determined to be authorized to use the services of thefirst communication network.
 22. The method of claim 21, wherein the setof identifications of the FAP comprises an international mobilesubscriber identity (IMSI) of the FAP.
 23. The method of claim 21,wherein the set of identifications of the FAP comprises an access pointidentification (AP-ID) of the FAP.
 24. The method of claim 21, whereinthe set of identifications of the FAP comprises a media access control(MAC) address of the FAP.
 25. The method of claim 21, wherein the set ofidentifications of the FAP comprises information identifying a serviceregion of the second communication network.
 26. The method of claim 25,wherein when the FAP detects coverage of a particular cell of the secondcommunication network, the information identifying the service region ofthe second communication network comprises a location areaidentification (LAI) and a cell identification of the particular cell ofthe second communication network.
 27. The method of claim 26, whereinwhen the FAP does not detects coverage of any cell of the secondcommunication network, the information identifying the service region ofthe second communication network comprises a location areaidentification (LAI) and a cell identification of a last cell of thesecond communication network with which the FAP had successfullyregistered.
 28. The method of claim 21, wherein request is sent by theFAP to a network controller of the first communication network, whereinthe network controller is for communicatively coupling the FAP with thesecond communication network.
 29. A computer readable medium storing acomputer for authorizing a Femtocell access point (FAP) of a firstcommunication system, the FAP is for communicatively coupling a userequipment with a second communication network, the computer programcomprising sets of instructions for: a) receiving a request forregistering the FAP with the first communication system, the requestcomprising a set of identifications of the FAP; b) based on saidinformation, determining whether the FAP is authorized to use servicesof the first communication network; and c) registering the FAP with thefirst communication network when the FAP is determined to be authorizedto use the services of the first communication network.
 30. The computerreadable medium of claim 29, wherein the set of identifications of theFAP comprises an international mobile subscriber identity (IMSI) of theFAP.
 31. The computer readable medium of claim 29, wherein the set ofidentifications of the FAP comprises an access point identification(AP-ID) of the FAP.
 32. The computer readable medium of claim 29,wherein the set of identifications of the FAP comprises a media accesscontrol (MAC) address of the FAP.
 33. The computer readable medium ofclaim 29, wherein the set of identifications of the FAP comprisesinformation identifying a service region of the second communicationnetwork.
 34. The computer readable medium of claim 29, wherein when theFAP detects coverage of a particular cell of the second communicationnetwork, the information identifying the service region of the secondcommunication network comprises a location area identification (LAI) anda cell identification of the particular cell of the second communicationnetwork.
 35. The computer readable medium of claim 34, wherein when theFAP does not detects coverage of any cell of the second communicationnetwork, the information identifying the service region of the secondcommunication network comprises a location area identification (LAI) anda cell identification of a last cell of the second communication networkwith which the FAP had successfully registered.
 36. The computerreadable medium of claim 29, wherein request is sent by the FAP to anetwork controller of the first communication network, wherein thenetwork controller is for communicatively coupling the FAP with thesecond communication network.
 37. A method of authorizing a Femtocellaccess point (FAP) of a first communication system, the FAP is forcommunicatively coupling a user equipment with a second communicationnetwork, the method comprising: a) receiving a request for registeringthe FAP with the first communication system; and b) rejecting said FAPrequest for registering with the first communication network when theFAP is in a service region of the second communication network where FAPaccess is not allowed.
 38. The method of claim 37, wherein saidrejecting comprises sending a register reject message from to the FAP,the register reject message comprising a reject cause.
 39. The method ofclaim 38, wherein the reject cause is location not allowed.
 40. A methodof authorizing user equipment (UE) to use services of a firstcommunication system comprising a Femtocell access point (FAP), the FAPis for communicatively coupling the UE with a second communicationnetwork, the method comprising: a) receiving at a server of the firstcommunication network a request for registering the UE with the firstcommunication system, said request sent from the FAP to the said server;the request comprising an identification of the UE; and b) rejecting therequest when the UE is determined not to be authorized to register withthe FAP.
 41. The method of claim 40, wherein the request comprises aninternational mobile subscriber identity (IMSI) of the UE.
 42. Themethod of claim 40, wherein the request comprises an internationalmobile subscriber identity (IMSI) of the FAP.
 43. The method of claim40, wherein the request comprises an access point identification (AP-ID)of the FAP.
 44. The method of claim 40, wherein the request comprises amedia access control (MAC) address of the FAP.